system-design

Part 7 — Security

Protecting the systems and data you’ve designed — from attackers, from mistakes, and from your own “we’ll add security later.”

Time for this part: Week 10 on the Standard track (alongside observability and deployment). Security questions appear in most design interviews, usually as “how would you secure this?” or “what could go wrong?”

The unifying idea across all seven chapters: security is a design concern, not a feature to bolt on — and the five principles behind it (never trust input, deny by default, least privilege, defence in depth, assume breach) apply everywhere.

---

Chapters

Identity and access

#	Chapter	Time	The problem it solves
1	Authentication vs Authorization	18 min	Who are you, and what may you do — and the #1 vulnerability
2	Sessions, JWTs, and OAuth 2.0 / OIDC	24 min	Remembering a login; delegated access; SSO

Protecting data

#	Chapter	Time	The problem it solves
3	Encryption in Transit and at Rest	20 min	Scrambling data, and the key management everyone gets wrong
4	Secrets Management	16 min	Credentials that must exist but never leak
7	Privacy, PII, and Compliance (GDPR)	20 min	When regulation becomes an architectural constraint

Defending against attack

#	Chapter	Time	The problem it solves
5	The OWASP Top 10	22 min	The ten most common breaches, as design decisions
6	DDoS Protection & Abuse Prevention	18 min	When the attack is drowning you in traffic

---

The five principles behind all of it

1. Never trust input — from users, clients, or other services. Validate, parameterize, encode.
2. Deny by default — access, network, and features are closed unless explicitly opened.
3. Least privilege — every user, service, and credential gets the minimum, to limit blast radius.
4. Defence in depth — multiple layers, so one failure isn’t a breach.
5. Assume breach — design for limited blast radius and reliable detection, because something eventually gets compromised.

---

The things to remember

• Authenticate once, authorize every action — especially per-resource. IDOR (broken access control) is the #1 vulnerability.
• Passwords are hashed (slow, salted), never encrypted. PII is encrypted; the two are different.
• JWTs are stateless but hard to revoke; sessions are revocable but stateful. Choose by whether you need instant logout.
• OAuth is authorization; OIDC is login. “Log in with Google” is OIDC.
• Secrets never touch git, and git never forgets. Prefer workload identity and dynamic secrets — no long-lived secret to leak.
• You can’t out-provision a botnet. DDoS defence is filtering (CDN/anycast), not absorbing.
• Data is a liability. Minimize collection; crypto-shred for erasure; pin data to its region.

---

Before moving on

You should be able to answer these without notes:

• Explain IDOR and how to prevent it.
• Explain why passwords are hashed not encrypted, and why with a slow algorithm.
• Choose between sessions and JWTs, and explain the revocation trade-off.
• Distinguish OAuth from OIDC.
• Explain envelope encryption and why keys live in a KMS.
• Explain workload identity and the secrets bootstrap problem.
• Name the top OWASP risks and how your design defends against each.
• Explain why you can’t out-provision a DDoS, and what you do instead.
• Explain crypto-shredding and how it reconciles erasure with immutable logs.

---

Next: Part 8 — Observability — you can’t secure, operate, or debug what you can’t see.

This site is open source. Improve this page.