Threat modeling asks what can go wrong, who could cause it, what assets are valuable, and which controls reduce risk. Identify assets such as credentials, personal data, payment records, signing keys, and administrative operations. Map trust boundaries between browser, API, worker, database, and third-party systems.

Use a structured method such as STRIDE to consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Prioritize threats by likelihood, impact, and exposure rather than treating every hypothetical risk equally.

Assume input can be malicious and internal networks are not automatically trustworthy. Validate data at boundaries, authenticate service identities, authorize every sensitive action, and log security-relevant events without recording secrets or unnecessary personal data.

Authentication establishes who or what is making a request; authorization determines which actions are permitted. Use least privilege and enforce authorization server-side for every object and operation. Hiding a button in the UI is not access control.

Sessions and tokens have different revocation and storage trade-offs. Short-lived access tokens limit exposure but require refresh and rotation strategies. Cookies need appropriate Secure, HttpOnly, and SameSite settings for the deployment context, and CSRF protections where relevant. JWT signatures do not encrypt claims unless an encryption format is used.

Store secrets in a managed secret store, restrict access, rotate credentials, and avoid placing secrets in source code, client bundles, logs, or error messages. Service-to-service authentication should use workload identity or scoped credentials where practical, not a shared permanent secret distributed to every component.

Use TLS for data in transit and appropriate encryption at rest for databases, backups, and object storage. Key management matters as much as encryption: control who can use keys, rotate them, audit access, and plan recovery. Encryption does not protect data from an application identity that is legitimately authorized but compromised.

Collect only data needed for a defined purpose. Establish retention and deletion policies, support access controls, and consider backups, replicas, caches, search indexes, and logs when implementing deletion. Privacy requirements should be reflected in architecture and operations rather than added at launch.

Rate limits protect services from accidental spikes and malicious abuse. Limits can be keyed by user, API key, IP, tenant, or resource cost. A fixed window is simple but can allow boundary bursts; token bucket allows controlled bursts; sliding-window methods provide more precise limits at extra cost. Pair rate limiting with quotas, anomaly detection, and graceful error responses.