We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
has no memory. When you send a GET request to a server, the server processes it, responds, and forgets you ever existed. The next request from the same browser is a complete stranger.
But web applications need continuity. Who is logged in? What is in their shopping cart? Which theme did they select? You need some mechanism to connect Request #1 to Request #47 from the same user.
Cookie-based sessions solve this with a simple idea: the server creates a session record (stored in , a database, or memory), generates a random session ID, and sends that ID to the browser as a cookie. On every subsequent request, the browser automatically attaches the cookie. The server reads the session ID, looks up the session data, and knows who you are.
This is the oldest and most proven session mechanism on the web. Django, Rails, Express with express-session, Laravel, and PHP all use cookie-based sessions by default. Shopify handles millions of active sessions this way. GitHub used cookie sessions for over a decade before adding any token-based flows.
The login flow:
SET session:a7f3b2 {userId: 42, role: admin} EX 86400Set-Cookie: sid=a7f3b2; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400Every subsequent request:
Cookie: sid=a7f3b2 (automatic, no JavaScript needed)GET session:a7f3b2 in Redis (0.2ms average)Cookie security flags matter more than most engineers realize:
| Flag | What It Does | What Happens Without It |
|---|---|---|
| HttpOnly | JavaScript cannot access the cookie | XSS can steal session IDs via document.cookie |
| Secure | Cookie only sent over HTTPS | Attacker on the same WiFi sniffs the session ID |
| SameSite=Lax | Blocks cross-origin POST requests from sending cookies | CSRF attacks work by tricking the browser into sending the cookie to your server from an attacker's page |
| Path=/ | Cookie sent for all paths on the domain | Narrower paths can break subpath routing |
| Max-Age | Cookie expires after N seconds | Session cookie deleted when browser closes (or never, depending on browser) |
The SameSite flag deserves special attention. Before SameSite, CSRF was one of the most common web vulnerabilities. An attacker's page could submit a form to your bank's transfer endpoint, and the browser would happily attach your session cookie. SameSite=Lax blocks this on POST/PUT/DELETE but still allows GET navigations (so links work). SameSite=Strict blocks everything cross-origin, which breaks redirects.
It is easy and good
“It is really nice and good Please join the course”