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.
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
TLS 1.2 vs TLS 1.3 — Head to Head
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).
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.
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
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
Set the algorithm to "none" and remove the signature. Many libraries accepted this as valid -- the token is "unsigned" but trusted.
// Attacker modifies header:
{ "alg": "none", "typ": "JWT" }
// Removes signature entirely
// Library says: "alg=none, no signature needed, VALID!"Always validate the algorithm server-side. Reject 'none'. Use an allowlist of accepted algorithms.
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.
Attacker inserts SQL code into input fields. The database executes it as part of the query, leaking or destroying data.
' OR 1=1 --
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)
Broken Access Control
Users can act outside their intended permissions. IDOR, privilege escalation, missing function-level access control.
Cryptographic Failures
Sensitive data exposed due to weak encryption, missing TLS, plaintext storage of passwords, weak hashing.
Injection
SQL, NoSQL, OS command, LDAP injection. User input interpreted as code or queries.
Insecure Design
Missing or ineffective security controls in the design phase. Threat modeling failures.
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.
Three Principles of Zero Trust
Verify Explicitly
Trust anyone inside the VPN perimeter
Authenticate and authorize every request based on identity, device, location, and behavior
Least Privilege Access
VPN grants broad network access
Grant minimum permissions needed, just-in-time, just-enough access
Assume Breach
Perimeter keeps attackers out
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
The sender and receiver. NOT your ISP, NOT the WiFi operator, NOT government surveillance (without the key).
Negotiated per-session via TLS handshake (ECDHE key exchange). Ephemeral keys -- even if one is compromised, past sessions are safe (forward secrecy).
TLS 1.3 with AES-256-GCM or ChaCha20-Poly1305
99% of Chrome browsing time is over HTTPS (TLS). Let's Encrypt serves 225M+ websites with free certificates.
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
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?+
What is the difference between authentication and authorization?+
Why should I use OAuth 2.0 instead of storing passwords?+
Are JWT tokens encrypted?+
How do I prevent SQL injection?+
What is a CSRF attack and is it still relevant?+
What is Zero Trust and how is it different from a VPN?+
What is the difference between encryption at rest, in transit, and end-to-end?+
How do I handle security in a system design interview?+
What are the most common security mistakes in production?+
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)