TheHowPage

System Design — Page 5

Security & Authentication

TLS handshakes, OAuth flows, JWT tokens, SQL injection, Zero Trust — how systems protect themselves from 47 million DDoS attacks per year and 21,500+ new vulnerabilities every six months.

DDoS attacks mitigated / hour

New CVEs published in 2025 H1

Record attack bandwidth

HTTPS adoption (Chrome)

Security isn't a feature — it's a property of every layer. In the first half of 2025, over 21,500 new CVEs were published. The Aisuru-Kimwolf botnet hit 200 million HTTP requests per second. The Salesloft breach exposed 700+ organizations through stolen JWT refresh tokens. SQL injection, first documented in 1998, is still in the OWASP top 5.

This page covers the seven security concepts that come up in every system design interview: TLS encryption, HTTPS, OAuth 2.0 authentication, JWT tokens, common web attacks, Zero Trust architecture, and encryption modes. Every demo uses real CVE data and real attack patterns.

If you haven't seen The Network Layer yet, start there — TLS builds directly on top of TCP. And Distributed Systems covers rate limiting and fault tolerance, which complement the DDoS protection discussed here.

The TLS Handshake — Encrypting in 1 Round Trip

Before any data flows, your browser and the server perform a cryptographic handshake. TLS 1.3 does it in 1 round trip (down from 2 in TLS 1.2) — a 30-50% latency reduction that made HTTPS nearly as fast as HTTP.

TLS 1.3 Handshake1-RTT (faster)
Client (Browser)Server

ClientHello

Browser sends supported cipher suites AND its key share in one message. TLS 1.2 needed a separate round trip for the key share.

Supported ciphers: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305
Key share: X25519 public key (32 bytes)
Supported versions: TLS 1.3
Step 1 of 3

TLS 1.2 vs TLS 1.3 — Head to Head

AspectTLS 1.2TLS 1.3
Round trips to connect2-RTT (4 messages before data)1-RTT (3 messages before data)
ResumptionSession IDs (server stores state)0-RTT PSK (data on first message)
Cipher suites37 suites (many weak: RC4, 3DES, SHA-1)5 suites (all strong: AES-GCM, ChaCha20)
Forward secrecyOptional (only with ECDHE)Mandatory (always ECDHE or DHE)
Handshake encryptionPlaintext (certificate visible to eavesdroppers)Encrypted after ServerHello (certificate hidden)
AdoptionStill 8-10% of connections90%+ of browser connections (Cloudflare: 92%)

From 30% to 99% — the HTTPS revolution

In 2014, only 30% of web traffic was encrypted. Google changed that with two moves: ranking HTTPS sites higher in search results (2014) and marking HTTP sites as “Not Secure” in Chrome (2018). Let's Encrypt launched in 2015 and eliminated the $100-300/year certificate cost. By 2026, 99% of Chrome browsing time is over HTTPS.

TLS 1.3 made encryption nearly free in terms of latency. The 1-RTT handshake means you add just one round trip (typically 10-30ms) before data flows. With 0-RTT resumption, returning connections send data on the very first packet. Cloudflare reports 40% of sessions use this — encrypted connections that feel as fast as unencrypted ones.

HTTP vs HTTPS — What the Attacker Sees

Without TLS, anyone on your network — the coffee shop WiFi, your ISP, a compromised router — can read every byte you send. 99% of Chrome browsing time is now over HTTPS. Chrome will enable HTTPS-First mode by default in October 2026 (Chrome 154).

Your message
Attacker's view (network sniffer)Plaintext
My password is hunter2. My credit card is 4242-4242-4242-4242.

The attacker can read your password, credit card, and everything else.

225M+

Let's Encrypt sites

63.9%

Market share

1.5M

Certs issued / day

110M+

Total certs online

The padlock protects the pipe, not the app

HTTPS encrypts data in transit — an attacker on your network can't read it. But it doesn't protect against the application-layer attacks that cause most breaches: stolen credentials, injected code, forged requests. That's why you need authentication (who are you?) and authorization (what can you do?) on top of encryption.

The modern standard: OAuth 2.0 for authentication delegation (“Login with Google”) and JWT tokens for stateless authorization. Both are elegant in theory and riddled with implementation pitfalls in practice.

OAuth 2.0 + PKCE — Login Without Sharing Passwords

OAuth 2.0 lets users “Login with Google/GitHub” without your app ever seeing their password. PKCE (Proof Key for Code Exchange) prevents authorization code interception — it's now required by RFC 9700 (January 2025) for ALL OAuth clients, not just mobile apps.

UserYour AppAuth ServerAPI
Your AppGenerate PKCE Challenge

The app generates a random string (code_verifier) and hashes it (code_challenge). This proves identity later without exposing a secret.

code_verifier = random(43-128 chars)
code_challenge = BASE64URL(SHA256(code_verifier))
Stored in memory only -- never sent to server yet
Step 1 of 7

The token OAuth gives you — and how to not screw it up

OAuth gives you an access token. In most modern systems, that token is a JWT — a self-contained, signed blob of JSON that the API can verify without hitting a database. It's stateless, scalable, and fast. It's also the source of some of the worst security bugs in the industry.

In 2025 alone, researchers found 6 major JWT CVEs. The Hono framework (used by thousands of Cloudflare Workers) had an algorithm confusion vulnerability rated CVSS 8.2. The Salesloft breach proved that refresh tokens without rotation are a ticking time bomb. Let's look at how JWTs work — and how they break.

JWT Tokens — The Good, the Bad, and the Exploitable

JWTs are everywhere — but they're also one of the most misunderstood security primitives. In 2025 alone, researchers found 6 major JWT CVEs including an algorithm confusion attack in the Hono framework (CVSS 8.2). The Salesloft breach exposed 700+ organizations via stolen refresh tokens.

Anatomy of a JWT — Decode It Live

Raw JWT Token

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQ1IiwibmFtZSI6IkphbmUgRW5naW5lZXIiLCJyb2xlIjoiYWRtaW4ifQ.dGhpc19pc19hX3NpZ25hdHVyZV9wbGFjZWhvbGRlcg

Contains claims -- data about the user and token. Anyone can decode this (it's just Base64). Never put secrets here.

{
  "sub": "user_12345",
  "name": "Jane Engineer",
  "email": "jane@company.com",
  "role": "admin",
  "iat": 1709827200,
  "exp": 1709828100
}

JWT Vulnerabilities — What Can Go Wrong

criticalAlgorithm "none" Attack

Set the algorithm to "none" and remove the signature. Many libraries accepted this as valid -- the token is "unsigned" but trusted.

The Attack
// Attacker modifies header:
{ "alg": "none", "typ": "JWT" }
// Removes signature entirely
// Library says: "alg=none, no signature needed, VALID!"
The Fix

Always validate the algorithm server-side. Reject 'none'. Use an allowlist of accepted algorithms.

Real-World Impact

CVE-2015-9235: auth0/jsonwebtoken accepted alg=none. Affected thousands of Node.js applications.

Authentication is the front door. Attacks come through the windows.

Even with perfect OAuth and JWT implementation, your application still has attack surface. SQL injection lets attackers read your database. XSS lets them execute code in your users' browsers. CSRF tricks authenticated users into making unintended requests. DDoS floods your servers until legitimate users can't get through.

The OWASP Top 10 has tracked these vulnerabilities since 2003. SQL injection has been on the list every single year. The fix — parameterized queries — has been known since day one. And yet, in 2025, injection is still ranked #3. Let's see why these attacks still work and how to stop them.

Common Attacks — SQL Injection, XSS, CSRF, DDoS

In the first half of 2025, over 21,500 new CVEs were published — more than all of 2020 combined. SQL injection is 26 years old and still in the OWASP top 5. The fix has been known since day one: parameterized queries. Yet here we are.

SQL InjectionOWASP #5 (2025) · 14,000+ CVEs

Attacker inserts SQL code into input fields. The database executes it as part of the query, leaking or destroying data.

Malicious Input
' OR 1=1 --
Attack Succeeds
Query becomes:
SELECT * FROM users WHERE username = '' OR 1=1 --'

OR 1=1 is always true -> returns ALL users
-- comments out the rest of the query

OWASP Top 5 (2025)

1

Broken Access Control

Users can act outside their intended permissions. IDOR, privilege escalation, missing function-level access control.

2

Cryptographic Failures

Sensitive data exposed due to weak encryption, missing TLS, plaintext storage of passwords, weak hashing.

3

Injection

SQL, NoSQL, OS command, LDAP injection. User input interpreted as code or queries.

4

Insecure Design

Missing or ineffective security controls in the design phase. Threat modeling failures.

5

Security Misconfiguration

Default credentials, unnecessary features enabled, missing security headers, verbose error messages.

DDoS by the Numbers (2025)

47.1M

Total attacks

121%

YoY increase

31.4 Tbps

Largest attack

4.8 billion pps

Peak packet rate

Patching holes vs redesigning the house

SQL injection, XSS, and CSRF are individual vulnerabilities — you fix them one by one. But what if your entire security model is flawed? The traditional approach (VPN/firewall perimeter) assumes: if you're inside the network, you're trusted. In 2009, Chinese hackers proved Google wrong.

Operation Aurora breached Google's internal network through a targeted attack on employees. Once inside the VPN, the attackers had broad access. Google's response: BeyondCorp, the blueprint for Zero Trust architecture. No more trusted networks. Every request verified. The $35.26 billion industry that followed.

Zero Trust — Never Trust, Always Verify

Google built BeyondCorp after Operation Aurora (2009) — a Chinese state-sponsored attack that breached their network through the VPN. The lesson: the network perimeter is not a security boundary. 81% of organizations plan adoption by 2026. 56% reported breaches via VPN-exploited vulnerabilities reported breaches exploiting VPN vulnerabilities.

Traditional (Castle & Moat)Attacker has access
Firewall / VPNEmployeeContractorAttacker (inside)DatabaseInternal APIAdmin PanelOnce past the firewall, attacker accesses everything — including admin panel

Three Principles of Zero Trust

Verify Explicitly

Traditional

Trust anyone inside the VPN perimeter

Zero Trust

Authenticate and authorize every request based on identity, device, location, and behavior

Least Privilege Access

Traditional

VPN grants broad network access

Zero Trust

Grant minimum permissions needed, just-in-time, just-enough access

Assume Breach

Traditional

Perimeter keeps attackers out

Zero Trust

Assume the attacker is already inside. Segment access, encrypt everything, detect anomalies

$35.26B (2026)

Market size (2026)

65% plan to replace VPN with Zero Trust

Plan VPN replacement

56% reported breaches via VPN-exploited vulnerabilities

VPN-exploited breaches

$4.88M (IBM, 2024) -- $1.76M less with Zero Trust deployed

Savings per breach

The last line of defense: make the data itself unreadable

Zero Trust verifies every request. But what if a verified request accesses data it shouldn't? What if the database is breached? What if a government demands access? The answer is encryption — and the level of encryption determines who can read the data, including whether you, the service provider, can.

AWS, Azure, and GCP all encrypt stored data with AES-256 by default. TLS encrypts data in transit. But end-to-end encryption (E2EE) goes further — the server itself cannot decrypt the data. WhatsApp uses the Signal Protocol for 3 billion+ users. The tradeoff: you can't search, index, or moderate E2E-encrypted content. Every level of encryption is a tradeoff between security and functionality.

Encryption — At Rest, In Transit, End-to-End

Three kinds of encryption, three different threat models. At rest protects stored data from physical theft. In transit protects data from eavesdroppers. End-to-end means even the service provider can't read your messages — WhatsApp uses the Signal Protocol for 3 billion+ users.

Where is data encrypted?

🔒 Your Device

Encrypted

🔒 Network / ISP

Encrypted

🔓 Server (App)

Plaintext

🔓 Disk / Storage

Plaintext

Who can read your data?

The sender and receiver. NOT your ISP, NOT the WiFi operator, NOT government surveillance (without the key).

Key management

Negotiated per-session via TLS handshake (ECDHE key exchange). Ephemeral keys -- even if one is compromised, past sessions are safe (forward secrecy).

Algorithm

TLS 1.3 with AES-256-GCM or ChaCha20-Poly1305

Real-world example

99% of Chrome browsing time is over HTTPS (TLS). Let's Encrypt serves 225M+ websites with free certificates.

Analogy

A sealed, tamper-proof envelope. The postal service carries it, but they can't read the contents. Only the recipient can open it.

Side-by-Side Comparison

AspectEncryption at RestEncryption in TransitEnd-to-End Encryption (E2EE)
Protects againstPhysical theft, disk breachEavesdropping, MITM attacksEveryone, including the service provider
Server can read data?Yes (decrypts to process)Yes (decrypts at destination)No (never has the key)
Compromised server impactData exposed (server has key)Future data exposedPast + future data safe
Search/index data?Yes (decrypted in memory)Yes (decrypted at server)No (server sees ciphertext only)
ComplianceRequired by HIPAA, PCI-DSS, SOC 2Required by GDPR, PCI-DSSExceeds most requirements
Performance cost<1% overhead (AES-NI hardware)1-RTT extra (TLS handshake)Slight CPU on device (key ratcheting)

Continue the Series

Security is cross-cutting — it touches every layer. Next up: monitoring and observability — the feedback loop that detects the attacks security defends against.

Frequently Asked Questions

What is TLS and why does it matter?+
TLS (Transport Layer Security) encrypts data between your browser and a server. Without TLS, anyone on your WiFi network can read your passwords, messages, and credit card numbers in plain text. TLS 1.3 (2018) reduced the handshake from 2 round trips to 1, making encrypted connections nearly as fast as unencrypted ones.
What is the difference between authentication and authorization?+
Authentication answers 'who are you?' (login with password, OAuth, biometrics). Authorization answers 'what can you do?' (roles, permissions, access control). OAuth 2.0 is technically an authorization framework -- it lets apps access resources on your behalf without sharing your password.
Why should I use OAuth 2.0 instead of storing passwords?+
With OAuth, you never see or store the user's password. Google/GitHub handle authentication, and you get a scoped access token. If your database is breached, attackers don't get passwords -- just tokens that expire in minutes. PKCE (RFC 9700, 2025) makes this even more secure by preventing authorization code interception.
Are JWT tokens encrypted?+
Standard JWTs (JWS) are signed but NOT encrypted. The payload is Base64-encoded, which anyone can decode. Never put passwords, API keys, or sensitive PII in a JWT payload. If you need encrypted tokens, use JWE (JSON Web Encryption), but it's less common and more complex.
How do I prevent SQL injection?+
Use parameterized queries (prepared statements). Never concatenate user input into SQL strings. In Node.js: db.query('SELECT * FROM users WHERE id = $1', [userId]). In Python: cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,)). ORMs like Prisma and SQLAlchemy do this by default.
What is a CSRF attack and is it still relevant?+
CSRF tricks authenticated users into making unintended requests. It's largely mitigated since Chrome defaulted to SameSite=Lax cookies in 2021 -- cross-site requests no longer send cookies by default. But you still need CSRF tokens for apps using SameSite=None (cross-origin APIs) or supporting older browsers.
What is Zero Trust and how is it different from a VPN?+
A VPN creates a trusted perimeter -- once inside, you can access everything. Zero Trust assumes the network is already compromised and verifies every single request: identity, device health, location, behavior. Google pioneered it with BeyondCorp after a state-sponsored breach in 2009. 81% of organizations plan to adopt Zero Trust by 2026.
What is the difference between encryption at rest, in transit, and end-to-end?+
At rest: data encrypted on disk (AES-256). The application server can decrypt it. In transit: data encrypted during transfer (TLS). The receiving server decrypts it. End-to-end: only the sender and recipient can decrypt. The server cannot read the data -- not even if compelled by law. WhatsApp uses E2EE via the Signal Protocol for 3B+ users.
How do I handle security in a system design interview?+
Mention security at every layer: TLS for all communication, OAuth 2.0 for authentication, short-lived JWTs for authorization, parameterized queries for database access, rate limiting for DDoS protection, and encryption at rest for stored data. End with: 'I'd also implement Zero Trust principles -- no service trusts another without verification.'
What are the most common security mistakes in production?+
Top 5: (1) Hardcoded secrets in code or environment variables without rotation, (2) Missing rate limiting on authentication endpoints, (3) JWT tokens that never expire or live too long (>15 min), (4) Using HTTP instead of HTTPS for internal service communication, (5) Logging sensitive data (passwords, tokens, PII) in plain text.

Sources & References

  • Cloudflare — TLS 1.3 Performance & Adoption Statistics (blog.cloudflare.com)
  • Let's Encrypt — Stats Dashboard (letsencrypt.org/stats)
  • IETF RFC 9700 — OAuth 2.0 Security Best Current Practice (2025)
  • OWASP Top 10 — 2025 Edition (owasp.org)
  • Cloudflare — 2025 Q4 DDoS Threat Report: 47.1M Attacks, 31.4 Tbps Record (blog.cloudflare.com)
  • Google BeyondCorp — A New Approach to Enterprise Security (research.google)
  • Signal Protocol — Technical Documentation (signal.org/docs)
  • IBM — Cost of a Data Breach Report 2024 ($4.88M average, $1.76M less with Zero Trust)
  • CVE-2026-22817 — Hono JWT Algorithm Confusion (CVSS 8.2)

Every explainer is free. No ads, no paywall, no login.

If this helped you, consider supporting the project.

Buy us a coffee