Security

7 min read

Designing Systems That Resist Attack

Security is not a feature you add at the end — it's a property that must be designed into a system from the start, because attackers only need to find one weakness while defenders must cover all of them. Every system that holds data or performs actions on behalf of users is a target, and the consequences of getting security wrong — breaches, data theft, fraud, regulatory penalties, lost trust — are among the most severe outcomes in software. This topic covers the foundational security concerns every system designer must understand: proving who users are and what they can do, protecting data with encryption, handling personal data lawfully, and defending against the most common classes of attack.

The unifying theme across these sub-topics is defense in depth and the principle that you should never trust input, never expose more than necessary, and never rely on a single control. Authentication and authorization gate access; encryption protects data even if other controls fail; input validation and output encoding stop injection and scripting attacks; privacy governance limits what's at risk in the first place; and secrets management keeps the keys to everything out of attackers' hands. No single one of these is sufficient — real security comes from layering them, so that any one failure is contained rather than catastrophic.

When This Comes Up

System design interviews: Security follow-ups are increasingly common: "How do users authenticate?" "How do you store passwords?" "How do you protect this data at rest and in transit?" "How do you prevent one tenant from accessing another's data?" Strong candidates weave security into the design — auth at the gateway, encryption everywhere, least privilege, input validation — rather than treating it as an afterthought.
Real architecture: Every design decision has a security dimension. Where auth is enforced, how data is encrypted and keys managed, how secrets are distributed, and how input is handled are foundational choices that determine whether a system is defensible. Compliance regimes (GDPR, HIPAA, PCI) turn many of these into hard requirements.
Production incidents: The vast majority of real-world breaches trace to the topics here — weak or broken authentication, broken object-level authorization, injection, XSS/CSRF, leaked secrets, and mishandled personal data. Knowing these classes and their defenses is what prevents your system from becoming the next headline.

How the Sub-Topics Connect

The sub-topics move from controlling access (authentication & authorization, OAuth2 & JWT) → protecting the data itself (encryption, data privacy) → defending against the most common attack classes (injection, XSS & CSRF) → and safeguarding the credentials that underpin it all (secrets management):

1. Authentication & Authorization

The two most fundamental controls: authentication proves who a user is (passwords hashed with slow salted algorithms, MFA combining factors, sessions vs stateless tokens), and authorization decides what they may do (RBAC, ABAC, ReBAC, least privilege). They're distinct steps with distinct failure codes (401 vs 403). The deepest lesson is the principle of least privilege — grant the minimum access to shrink the blast radius of any compromise — and the most common failure is broken object-level authorization (a valid token accessing another user's data), prevented by checking resource ownership on every access.

2. OAuth2 & JWT

The standards behind modern login and stateless auth. OAuth 2.0 enables delegated authorization — granting a third-party app scoped access without sharing your password (the basis of "Sign in with…", with OpenID Connect adding the identity layer). JWT is a self-contained, signed token format that lets any service verify identity and permissions by checking a signature — no database lookup — which is what makes auth scale across microservices. The critical cautions: a JWT payload is signed, not encrypted (readable by anyone), JWTs are hard to revoke (use short lifetimes + refresh tokens), and misuse (alg: none, algorithm confusion, unvalidated claims) causes real breaches.

3. Encryption

The primary tool for confidentiality, applied in two states: in transit (TLS/mTLS — encrypt everywhere) and at rest (disk, database, and field-level for the most sensitive data). Two algorithm families — fast symmetric (AES) for bulk data and slower asymmetric (RSA/ECC) for key exchange and signatures — are combined in hybrid schemes like TLS. Encryption is distinct from hashing (one-way, for passwords). Its strength depends entirely on key management — envelope encryption with a KMS/HSM, rotation, and separating keys from data — and the universal rule: never roll your own crypto; use vetted standard algorithms and libraries.

4. Data Privacy

Where security is about keeping data safe, privacy is about handling personal data responsibly and lawfully — collecting only what's needed, using it only for stated purposes, keeping it only as long as necessary, and honoring individuals' rights (access, deletion, portability). Regulations like GDPR and CCPA make these legal obligations with steep penalties. The key techniques are anonymization, pseudonymization, and tokenization, and the key architectural move is privacy by design — isolating raw PII into a guarded vault and referencing users by token, which makes minimization, breach containment, and the hard problem of the "right to erasure" tractable.

5. Input Validation & Injection

Injection — SQL, NoSQL, command, template — is when untrusted input is interpreted as code rather than data, and it has topped the OWASP risk list for years. The root cause is mixing data and code; the primary defense is parameterized queries that keep the two strictly separate, backed by allowlist input validation, least-privilege database accounts, and safe-by-default ORMs. The mindset that prevents injection — treat all input as untrusted and never let it cross into an interpreter as code — is enforced through defense in depth, so a single missed spot doesn't become a catastrophe.

6. XSS & CSRF

Two of the most common web vulnerabilities, and opposites often confused. XSS runs attacker script in a victim's browser on a trusted site (abusing the user's trust in the site) — defended by context-aware output encoding, CSP, and HttpOnly cookies. CSRF forges an authenticated request by riding the victim's cookies (abusing the site's trust in the browser) — defended by CSRF tokens and SameSite cookies. They interact critically: a successful XSS defeats CSRF defenses (script can read the tokens), which is why XSS is the higher-priority class and both must be closed together.

7. Secrets Management

The discipline of storing, distributing, rotating, and auditing the credentials that underpin everything — database passwords, API keys, encryption keys, tokens. Leaked secrets (in Git, config, logs) cause a huge share of breaches, so the anti-patterns (hard-coding, committing, plaintext config) must be replaced with a secrets manager that provides encrypted storage, least-privilege access, audit logging, and rotation. The key patterns are runtime retrieval (apps fetch secrets via their workload identity, so repos/images contain none) and dynamic short-lived secrets (nothing long-lived to steal) — plus the rule that an exposed secret must be rotated, not just deleted.

Sub-Topics

#	Sub-Topic	What You'll Learn
1	Authentication & Authorization	Verifying identity and enforcing least-privilege access
2	OAuth2 & JWT	Delegated login and stateless token-based auth
3	Encryption	Protecting data in transit and at rest, and key management
4	Data Privacy	Handling personal data lawfully and by design
5	Input Validation & Injection	Stopping SQL and other injection attacks
6	XSS & CSRF	Defending against the two most common web attacks
7	Secrets Management	Keeping credentials out of code and attackers' hands