Security basics for design

Start with the threat, not the checklist

Security in a design interview is not a list of acronyms. It is three questions asked in order: what are we protecting (accounts, payment data, other people's private messages), who might attack it (an anonymous visitor, a logged-in user going after someone else's data, an employee, a compromised dependency) and what do they gain if they succeed. Once you can say "the worst case here is one user reading another user's orders", every control you add has a reason, and every control you leave out is a decision you can defend.

Two habits carry most of the weight. Defense in depth: assume any single control will fail, so a stolen token should still be short-lived, still be scoped, still be logged. Least privilege: every user, service and credential gets only what its job needs, so a leak of one does not open everything.

Authentication is who you are; authorization is what you may do

Authentication establishes identity (a password, a passkey, a token). Authorization decides whether that identity may do this thing to this object. The two are separate checks, and the second is the one that fails in real systems: broken access control is the first category of the OWASP Top 10 in both the 2021 and the 2025 editions. The classic form is the insecure direct object reference. A request for GET /orders/8731 is authenticated, so the server returns the order, never checking that order 8731 belongs to the caller. Changing the number in the URL then walks through every customer's orders.

Sessions, tokens and OAuth: what each one is for

OAuth 2.0 is a framework for delegated authorization: a user lets one application act on their behalf at another without giving it their password. It is not a login protocol by itself. OpenID Connect adds an ID token on top, which is the part that says who the user is. For a browser or mobile app the flow is the authorization code flow with PKCE: the app sends the user to the identity provider with a hashed one-time challenge, the provider returns a short-lived code, and the app exchanges the code plus the original secret for tokens. The current OAuth security best-practice document (RFC 9700) says public clients must use PKCE, that the password grant must not be used and the implicit grant should not be, and that redirect URIs must match exactly.

JWT pitfalls are worth naming, because the format looks safer than it is. RFC 8725 lists them. Verify the signature with the algorithm you expect, never the one the token's own header claims, and reject none. Check the issuer, the audience and the expiry on every use. The payload is only base64url encoded, so anyone can read it: never put a secret in it. Plan key rotation with a key id so that you can publish a new key before retiring the old one. And on the client, a cookie marked HttpOnly keeps the token away from scripts (Secure and SameSite limit where it is sent), while a token in localStorage is readable by any cross-site scripting bug. A script can still make requests from the page while it is open, and cookies bring request forgery back, so neither choice replaces fixing the script bug.

Passwords, passkeys and second factors

Never store a password, and never store anything that can be turned back into one. Store the output of a slow, memory-hard hash with a unique random salt per user. The OWASP password storage cheat sheet puts Argon2id first, with minimum settings of about 19 MiB of memory, 2 iterations and 1 degree of parallelism, then scrypt, and keeps bcrypt (work factor of at least 10, and a 72-byte input limit) for legacy systems; PBKDF2 at a very high iteration count is the option where FIPS validation is required. A pepper, a secret kept outside the database, adds defense in depth, but it is not a substitute for the salt and the slow hash. Compare hashes in constant time and rate limit the login endpoint (see the rate limiting chapter), keyed by address as well as by account.

The stronger move is to need fewer passwords. A passkey (WebAuthn) is a public-key credential held by the user's device: the server stores only a public key, so there is nothing to phish and nothing to leak from your database that an attacker can replay on another site. A second factor (a one-time code, a hardware key) limits the damage when a password is stolen anyway.

Authorization models: roles, attributes and relationships

Google's Zanzibar paper describes the relationship model at scale: access is stored as tuples of the form object, relation, user, and a check walks them, which is how one system answers "may Alice open this file?" for Drive, Photos and YouTube. Where it gets hard is exactly the part earlier chapters warned about: a permission cache is a replica, so a revoked permission keeps working for as long as a stale answer lives. Decide how stale an authorization answer may be, and let the sensitive actions bypass the cache.

Encryption: in transit, at rest, and who holds the keys

• In transit: TLS everywhere, including between your own services, because a flat internal network is not a security boundary. Mutual TLS makes both ends present certificates, which gives each service a verifiable identity (a service mesh automates the certificates).
• At rest: disk or volume encryption protects against a stolen disk and a discarded server. It does nothing against an attacker who gets your application's credentials, because the application sees decrypted data. For sensitive fields (card numbers, national ids) encrypt or tokenize them in the application so the database never holds plaintext.
• Envelope encryption: a key management service holds a root key (AWS calls it a KMS key) that never leaves it. For each object you generate a data key, encrypt the data with it, then encrypt the data key with the master key and store the two together. Changing the wrapping key means re-wrapping small data keys, not re-encrypting terabytes (AWS KMS's automatic rotation keeps the old key material, so even that is needed only when you move to a new key).
• Secrets: keep them in a secrets manager, inject them at runtime, give them a short life or rotate them, and never commit them to a repository, bake them into an image or write them to a log. A leaked secret should mean "rotate and redeploy", not "emergency".

The attacks an interviewer expects you to name

Dry run: reviewing a small design for flaws

A notes app stores each user's notes. Its API is GET /notes/{id}. Login returns a JWT valid for 24 hours, which the single-page app keeps in localStorage. Passwords are stored as an unsalted SHA-256 of the password. A design review finds four problems.

How cheap is the guessing? An eight-letter lowercase password has 26⁸ = 208,827,064,576 possibilities. At an illustrative 10 billion fast hashes a second on a single modern graphics card, that is about 21 seconds to try every one. A memory-hard hash with a salt does not make a bad password good, but it turns a 21-second job into one that costs real money per guess and cannot reuse work across users.

Recognizing it in an unseen problem

• Signals: any mention of users, accounts, payments, health data, multi-tenant data, or a third-party login. Say the security section out loud even if the prompt does not ask: it is expected at senior level.
• The naive design authenticates at the edge and trusts everything behind it. Name the missing per-object authorization check, the long-lived token and the plaintext secrets.
• Multi-tenant prompts (one service, many customers) make the tenant id part of every key, query and cache entry. A missing tenant filter is the data-leak bug.
• Distinguish authentication, authorization and encryption: they fail in different ways and need different fixes.
• Quantify the blast radius: "a leaked access token is good for 15 minutes and one scope" is a design statement. "We use JWT" is not.
• The pitfall: inventing your own cryptography or token format. Use a managed identity provider, a standard flow and a vetted library.