Defense in depth: the breach lives in the seam

The login flow is textbook. Passwords are Argon2id-hashed, the session is a short-lived JWT, TLS is enforced with HSTS, the API key sits in a vault. Then a user changes the id in GET /accounts/{id}/statements and reads someone else’s bank statements. No control was broken. Authentication verified who the caller was — flawlessly — and then the statements endpoint simply never asked whether this caller may read this record. Every layer passed its own test. The breach lived in the gap between them.

One request, six layers

Trace a single sensitive action — a logged-in user transfers money — and you pass through every control the security track has covered. Each is a distinct layer with its own job, and a senior reasons about them as a stack, not a checklist:

1. Transport — TLS plus HSTS so the request can’t be read or downgraded to plaintext on the wire.
2. Authentication — prove who is calling. A short-lived access token (minutes, not days), passwords stored as Argon2id or bcrypt hashes, never the password itself.
3. Authorization — decide whether this caller may do this to this object. Deny-by-default, least privilege. This is OWASP’s #1 risk for a reason.
4. Input handling — treat every field as hostile: validate, parameterize queries, encode output.
5. Secrets — keys and DB credentials live in a vault or env, never in the repo, never in the JWT.
6. Supply chain — the dependencies executing all of the above are themselves vetted and pinned.

The thesis of the whole track lands here: defense in depth assumes every control eventually fails. You stack them so that when the first barrier goes down, the second slows the attacker and the third raises an alert. The mistake juniors make is treating one strong control as the answer.

The breach lives in the seam

The dangerous failures are not a missing layer — those get caught in review. They are two correct layers that don’t compose. The hook is the canonical example: authentication answered “yes, this is a valid logged-in user,” and the endpoint trusted that answer to mean “…so let them read the record,” which authentication never claimed. AuthN is not AuthZ. Knowing who someone is tells you nothing about what they may touch.

OWASP ranks Broken Access Control as A01 — the most common serious flaw — precisely because it lives in these seams. The fix is structural, not a patch on one route: enforce authorization in trusted server-side code, deny by default for every non-public resource, and check record ownership on the object the request names, not just the route. An attacker who flips {id} in GET /accounts/{id}/statements is doing IDOR; the only thing that stops it is the server asking “does this subject own this object?” on every request.

The JWT-in-localStorage seam

The token-storage decision is a pure composition problem, so it deserves a close look. A perfectly minted JWT — signed, short expiry, correct claims — is defeated by where you put it. Store it in localStorage and any successful XSS runs localStorage.getItem('token') and exfiltrates it to the attacker’s server; the token’s own strength is irrelevant once JavaScript can read it. The mitigation is an HttpOnly cookie, which JavaScript cannot touch, so XSS can’t steal it — but cookies are sent automatically cross-site, which reopens CSRF. You close that with SameSite plus a CSRF token. Notice the shape: each fix solves one layer and exposes the seam with the next. There is no single setting that wins; you compose HttpOnly + Secure + SameSite + short TTL, and you still have to kill XSS at the source with output encoding and CSP, because an attacker who can run script in your origin has already moved past the storage question.

Least privilege everywhere, not just at the door

Defense in depth is also about blast radius. When a layer does fail — and the model assumes one will — least privilege decides how far the damage spreads. The vault credential the API uses should grant only the rows and operations that endpoint needs, so a compromised service can’t drain the whole database. The access token should be short-lived so a stolen one expires in minutes, not weeks. The dependency you pulled in should run with the same scrutiny, because a malicious transitive package executes inside your trust boundary. NIST SP 800-63B and the OWASP password guidance set the floor for the auth layer — Argon2id tuned to roughly 250–500ms per hash, or bcrypt at cost factor 12+, with a unique per-user salt — but a strong hash behind an unrate-limited reset endpoint still falls. The number on one layer never excuses a gap in the next.