Securing a System — Defense in Depth, Layer by Layer

Security questions in a system-design round rarely ask "is this secure?" — they ask "what breaks, and what stops it?" The failure mode juniors show is naming one control ("we'll use JWTs") as if it secured the system. It didn't. Security is defense in depth: a request must clear a stack of independent layers, and for each you name the threat it faces and the mechanism that mitigates it. This page is the decision layer on top of the guide's auth, encryption, and secrets pages: layer → threat → control → mechanism.

The layers — for each, the threat and the named control

These are independent: defeating one buys the attacker nothing if the next holds. You address each layer explicitly rather than assuming one strong control covers the rest.

Layer	Threat if absent	Control	Mechanism to name
Identity / AuthN — who are you?	Impersonation; stolen/replayed credentials	Verify identity; add a second factor for sensitive actions	Sessions vs tokens, OIDC, MFA / step-up
Authorization — what may you do?	Privilege escalation, IDOR (read someone else's object by guessing an id)	Least privilege; check every request against the resource	RBAC / ABAC, ReBAC / Zanzibar
Transport — data in motion	Eavesdropping, man-in-the-middle	Encrypt the channel; authenticate both ends between services	TLS / mTLS, forward secrecy
Data at rest & secrets	Database dump exfiltrates everything; a leaked key unlocks it	Encrypt stored data; keep keys out of code; rotate	Envelope encryption, KMS / vault, short-lived creds
Input & abuse	Injection (SQL/command), flooding, scraping	Never trust input; bound the request rate	Parameterized queries, output encoding, rate limiting
Audit & detection	A breach goes unnoticed for months	Log security-relevant events; alert on anomalies	Immutable audit log, anomaly detection

The decision rule

1. Walk the request through the layers. For the feature on the table, ask at each layer: "what's the threat here, and is a control present?" A gap at any layer is the answer the interviewer is fishing for.
2. Match the control to the sensitivity. A public read needs transport + rate-limiting; a money movement needs all of it plus step-up MFA and an audit trail. Don't over-secure a view counter or under-secure a payout.
3. Name the mechanism, not the wish. "We'll secure it" is nothing; "OIDC for authN, ReBAC checks per request, mTLS between services, envelope-encrypted PII with rotated KMS keys, parameterized queries, and an append-only audit log" is a defensible answer.

Worked example — "Login with Google, then move money"

Trace one sensitive request down the stack; each layer contributes one control:

• AuthN: OIDC "Login with Google" establishes identity; the app mints its own session/JWT. For the payout, step-up MFA — re-prove identity for the sensitive action, not just at login.
• AuthZ: being logged in doesn't mean you may move this account's money — a per-request check ("does subject S have transfer on account A?") stops IDOR.
• Transport: TLS to the edge; mTLS between the payment services so an internal caller can't be spoofed.
• Data & secrets: card/PII envelope-encrypted; the signing key lives in a KMS and rotates — never in the repo or an env file baked into an image.
• Abuse: the transfer endpoint is rate-limited per account to blunt credential-stuffing and enumeration.
• Audit: the transfer emits an immutable event — who, what, when — so a compromise is detectable and reconstructable.

Six layers, six controls, one request. Naming each — and where the guide covers it — is the depth the question is testing.

Traced: one layer fails — who catches it?

The worked example shows every layer holding on a legitimate request. Independence is only proven when a layer breaks — so trace two breaches where one fails outright and name the exact control that stops the next step.

Chain 1 — XSS lands on the payments page (Input layer FAILED).

1. A stored-XSS payload slips past output encoding and runs in the victim's browser on the payments page. The input layer has already lost; assume the script runs.
2. The script reads document.cookie to exfiltrate the session — blocked by HttpOnly: the session cookie is invisible to JavaScript, so token theft is off the table.
3. It pivots: instead of stealing the session it acts as the user, firing an in-page transfer request (the browser attaches the cookie automatically) — blocked by step-up MFA on the payout action: moving money demands a fresh second factor the script cannot produce.
4. The failed step-up emits an audit event; a transfer attempt with no fresh MFA from an odd context is exactly what anomaly detection alerts on — the Detection layer turns a contained attack into a caught one.

Chain 2 — an internal service is compromised (the perimeter assumption FAILED).

1. An attacker gains code execution on an internal utility service. "It's inside the network" is now worth nothing; every east–west call from that pod is hostile.
2. It calls the payment service directly — blocked by mTLS workload identity: the compromised pod holds no valid client certificate for the payment service, so the connection never even authenticates.
3. It tries the database instead — blocked by network policy: app pods cannot reach the DB directly (the layer the scale-honesty section sized), so a single owned pod is not a data dump.
4. The refused connections are anomalous east–west traffic from a pod that never makes those calls; the alert pages on-call before the attacker finds a fourth move.

One caveat keeps this honest: correlated failures collapse layers. Two controls that share a dependency — the same secret store, the same misconfigured template, one wildcard certificate — are one layer wearing two names. When you count your depth, count only independent controls.

Scale honesty — the controls have capacity too

Depth-in-layers is a threat argument, but each layer is also a system with a capacity budget, and a control that becomes a bottleneck or a hard dependency is its own outage. Size them explicitly. At, say, 100k rps: the edge (TLS + WAF) must be provisioned for peak plus attack headroom, with an explicit fail-open-vs-fail-closed policy — a blocking WAF rule untested at peak drops revenue on a false positive. AuthN should validate JWTs locally (cheap CPU) rather than calling a remote introspection endpoint per request — turning auth into a synchronous 100k-rps dependency is usually the wrong trade; short TTLs plus a scoped revocation check buy back the revocation you gave up. AuthZ decisions cache with a short (10–60s) TTL bounded by a consistency token. Audit at that volume is itself a capacity problem: sample or aggregate high-volume reads but fully log privileged and export paths — raw logging of every request is often infeasible, so state the trade-off. And a network policy that forbids app pods from reaching the database directly means a single compromised web pod is not a full data dump: lateral movement is blocked at the layer boundary, which is the entire point of depth.

Traps to avoid

• Confusing AuthN with AuthZ. Authenticated is not authorized — the classic IDOR is a valid login reading an object it shouldn't. Authorize every request against the resource, not just the session's existence.
• Rolling your own crypto or auth. Use vetted protocols (OIDC, TLS, argon2/bcrypt); a hand-rolled token scheme or cipher is a vulnerability you wrote yourself.
• Secrets in code / env / images. They leak via repos, logs, and layer caches. Keep them in a KMS/vault, inject at runtime, rotate, and prefer short-lived credentials.
• Trusting the client. Client-side checks are UX, not security — re-validate and re-authorize on the server. Never trust a price, a role, or an id the client sent.
• One control = "secure". A JWT doesn't encrypt transport, authorize actions, or protect data at rest. Depth means each layer is addressed on its own.

Related: AuthN vs AuthZ · Sessions vs tokens · JWT signing & rotation · MFA / step-up · AuthZ: Zanzibar & revocation · TLS / mTLS handshake · Forward secrecy & certificates · Encryption.

---

Re-authored/Deepened for this guide.

I just read a lesson on **Securing a System — Defense in Depth, Layer by Layer** (System Design) and want to truly understand it. Explain Securing a System — Defense in Depth, Layer by Layer from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Securing a System — Defense in Depth, Layer by Layer** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Securing a System — Defense in Depth, Layer by Layer** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Securing a System — Defense in Depth, Layer by Layer** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.