Security · Lesson 09

Cookies, sessions & CSRF

HTTP is born without memory — every request stands alone. Cookies are the mechanism that bolts memory on top, and that mechanism, when misused, creates one of the most persistent attack classes in web security: Cross-Site Request Forgery.

The statelessness problem

Imagine a hotel that forgets you exist the moment you step out of the lobby. Every time you return you'd have to introduce yourself from scratch. HTTP is that hotel. By design, each request carries no memory of earlier ones. That property keeps servers simple and scalable, but it means every HTTP request that needs context — "who are you?", "what's in your basket?" — must carry that context explicitly.

Cookies are the envelope the browser uses to carry that context automatically. They're small key-value strings the server plants in the browser via a response header, and the browser re-attaches to every subsequent matching request without the developer writing a single line of code for it.

How a cookie is born and reused

The server sends a Set-Cookie header in a response. From that moment the browser stores the cookie and echoes it back on every request to the same origin — until it expires or the server deletes it.

Set-Cookie attributes that matter for security

A naked Set-Cookie: session=abc123 is a security hole with a ribbon on it. The following attributes close those holes one by one:

Session auth vs. token auth

The session ID is just a pointer — a random string that maps to the real user data stored server-side. Token auth (most commonly a JWT in the Authorization: Bearer header) inverts this: the token itself carries the claims, and the server validates the signature without querying a store.

The right choice depends on the access pattern. For a browser-based web app where revocation on logout matters, sessions fit well. For a distributed API serving mobile and third-party clients, stateless JWT in a header removes the coordination overhead — but you must keep expiry short and maintain a token denylist for critical revocation scenarios (leaked credential, account deletion).

CSRF: when the browser's helpfulness becomes a weapon

Cross-Site Request Forgery exploits the one thing that makes cookies convenient: the browser sends them automatically, even on requests triggered by a different website. Imagine you log into your bank at bank.example. Your session cookie sits in the browser's jar. Now you visit a malicious page at evil.example that contains:

<!-- On evil.example — the user never sees this form -->
<form method="POST" action="https://bank.example/transfer">
  <input name="to"    value="attacker_account" />
  <input name="amount" value="5000" />
</form>
<script>document.forms[0].submit();</script>

The browser fires a POST to bank.example/transfer and, because the session cookie's Domain matches, it attaches it. The bank server sees a valid authenticated request. The transfer goes through. The victim never clicked anything.

Notice why a JWT in Authorization: Bearer doesn't have this problem: the browser has no built-in mechanism to add a custom header to a cross-site form submission. Only cookies travel automatically.

CSRF defences

Three approaches, layered or used individually:

1. SameSite=Lax or Strict. The modern first line of defence. Lax blocks cross-site POST/fetch while allowing top-level navigations. Strict blocks everything cross-site. Either kills the hidden-form attack above. All browsers since 2021 default to Lax even when you don't ask — but set it explicitly; never rely on browser defaults.
2. CSRF tokens (synchroniser token pattern). The server generates a secret random value when it issues the session, stores it, and embeds it in every form as a hidden field and/or a cookie. On each state-changing request, the server checks that the submitted token matches. The attacker's page cannot read the token (same-origin policy blocks it), so forged requests fail even if they carry the session cookie.
3. Double-submit cookie. Server sets a second cookie with a random value; the client copies it into a custom header (e.g. X-CSRF-Token). Server verifies they match. Because evil.example can't read or set cookies on bank.example, it can't forge the header value. Simpler for SPAs than the synchroniser pattern, but weaker if there's a subdomain compromise.

Worked example: a secure login flow

Here's a complete login sequence with a hardened Set-Cookie and a CSRF token for a subsequent state-changing call:

# Step 1 — client authenticates
POST /v1/auth/login HTTP/1.1
Host: api.acme.com
Content-Type: application/json

{ "email": "ada@example.com", "password": "correct-horse-battery" }

# Step 2 — server responds with a hardened session cookie
HTTP/1.1 200 OK
Set-Cookie: sid=8f3a9c12d7; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
Content-Type: application/json

{ "csrf_token": "v2:nonce:HmacSha256(...)" }

# Step 3 — client makes a state-changing request
POST /v1/transfers HTTP/1.1
Host: api.acme.com
Cookie: sid=8f3a9c12d7                     # browser sends automatically
X-CSRF-Token: v2:nonce:HmacSha256(...)        # client must add this explicitly
Content-Type: application/json

{ "to_account": "acc_7890", "amount_cents": 1500 }

# Step 4 — server validates both the session AND the CSRF token before acting
HTTP/1.1 201 Created

Under the hood: how it actually works

Understanding the exact decision tree the browser runs when it receives and re-sends a cookie lets you predict the behavior and debug without guessing.

Step 1 — parsing Set-Cookie

When the browser receives a Set-Cookie response header it extracts these fields and stores them together as one cookie record:

# Full Set-Cookie header the browser parses:
Set-Cookie: sid=8f3a9c12d7; HttpOnly; Secure; SameSite=Lax; Path=/; Domain=api.acme.com; Max-Age=3600

# What the browser stores internally (conceptual record):
{
  name:       "sid",
  value:      "8f3a9c12d7",
  domain:     "api.acme.com",    // no leading dot → only exact host
  path:       "/",
  expiry:     now + 3600s,
  http_only:  true,
  secure:     true,
  same_site:  "Lax"
}

Step 2 — the browser's "should I send this cookie?" decision tree

Before each outgoing request the browser runs this algorithm for every cookie in its jar:

Step 3 — server-side session lookup vs. JWT on the wire: a concrete trace

Here is the exact wire exchange for the same authenticated GET, once with session auth and once with JWT, so you can see what differs at each hop:

── Session auth (cookie) ────────────────────────────────────────────
# Browser → Server
GET /v1/account HTTP/1.1
Host: api.acme.com
Cookie: sid=8f3a9c12d7     ← opaque pointer; browser added automatically

# Server does:
1. Extract "8f3a9c12d7" from Cookie header.
2. SELECT * FROM sessions WHERE id = '8f3a9c12d7' AND expiry > NOW();
3. Row found → read user_id = 42, role = 'editor'.
4. Proceed with request.   ← requires DB/Redis round-trip on every request

── JWT auth (Authorization header) ──────────────────────────────────
# Browser/client → Server
GET /v1/account HTTP/1.1
Host: api.acme.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJlZGl0b3IiLCJleHAiOjE3NTAwMDM2MDB9.<sig>

# Server does:
1. Split token at dots → header / payload / signature.
2. Decode header: { "alg": "RS256", "kid": "key-2025-06" }
3. Fetch public key for "key-2025-06" from in-memory JWKS cache.
4. Verify: RSA_verify(header+"."+payload, signature, public_key) → OK
5. Decode payload: { "sub": "42", "role": "editor", "exp": 1750003600 }
6. Check exp > now() → valid.
7. Proceed.   ← no DB round-trip; claims are self-contained in token

Concrete CSRF execution trace — and why SameSite blocks it

Walk through the attack step by step to see exactly where SameSite intervenes:

── Without SameSite (pre-2021 behaviour or SameSite=None) ──────────

1. User logs into bank.example → receives:
   Set-Cookie: sid=USER_SESSION; Path=/; Secure   ← no SameSite
   Browser stores cookie: domain=bank.example

2. User visits evil.example.  Page contains hidden form:
   <form method="POST" action="https://bank.example/transfer">
     <input name="amount" value="5000"><input name="to" value="attacker">
   </form>
   <script>document.forms[0].submit()</script>

3. Browser fires POST to bank.example/transfer.
   Domain match: YES.  Path: YES.  Secure+HTTPS: YES.
   SameSite check: cookie has no SameSite → no restriction → SENT

4. bank.example sees:
   POST /transfer  Cookie: sid=USER_SESSION   ← attacker's transfer executes

── With SameSite=Lax (modern default) ──────────────────────────────

3. Browser fires POST to bank.example/transfer from evil.example.
   SameSite check: request is cross-site (evil.example ≠ bank.example)
                   AND method is POST (not a top-level GET navigation)
                   → cookie WITHHELD

4. bank.example sees:
   POST /transfer  (no Cookie header)  ← server returns 401; transfer blocked

── With SameSite=Strict ─────────────────────────────────────────────

3. Even a cross-site GET navigation (clicking a link from evil.example
   to bank.example) would withhold the cookie.
   Any cross-site origin → cookie withheld.
   Note: this breaks "return to site after OAuth redirect" flows.

How to debug & inspect it

The fastest path is DevTools → Application → Cookies. Cookies that exist but are not being sent are the classic symptom — you can see them in the jar but they do not appear in the request headers.

When a cookie exists in the jar but does not appear in a request, work through this symptom table:

Cookie debug checklist:

1. Open DevTools → Application → Cookies → select the origin. Confirm the cookie is stored and note every attribute column.
2. Open DevTools → Network → select the failing request → Headers tab. Is the Cookie header present? If not, start at row 1 of the symptom table above.
3. Check the Domain column. A cookie set for api.acme.com will NOT be sent to www.acme.com — they are different hosts unless a dot-prefixed domain was used.
4. Check the SameSite column. If blank (no attribute), Chrome/Firefox now treat it as Lax; Safari may treat it differently. Set it explicitly.
5. For CSRF debugging: can you reproduce the attack with curl? (curl -b cookies.txt -X POST https://target/transfer will succeed because curl doesn't enforce SameSite — that's expected and confirms the server needs its own CSRF check.)
6. Confirm the server validates the CSRF token on every state-changing request — add a breakpoint or log on the server-side CSRF check and watch it fire.

HTTP/1.1 200 OK
Set-Cookie: auth=USER_42_ADMIN; Domain=.acme.com; Path=/

# Problems in the original:
# 1. auth=USER_42_ADMIN — embeds user ID and role in plain text in the cookie
#    value. Anyone who can read the cookie (or intercept it) sees this data.
# 2. No HttpOnly — JavaScript can steal it via XSS.
# 3. No Secure — cookie travels over HTTP in cleartext.
# 4. No SameSite — cookie is sent on all cross-site requests (CSRF risk).
# 5. Domain=.acme.com is broad — applies to all subdomains; a compromised
#    subdomain can read/set this cookie.
# 6. No Max-Age/Expires — cookie lives forever in the browser.

# Corrected header:
HTTP/1.1 200 OK
Set-Cookie: sid=<opaque-random-128-bit-token>; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Sources & further reading

• MDN — Using HTTP cookies — complete Set-Cookie attribute reference
• OWASP — CSRF Prevention Cheat Sheet — synchroniser token, double-submit, SameSite in depth
• MDN — Same-origin policy — why cross-site JS can't read your cookie but form POSTs still carry it
• web.dev — SameSite cookies explained — Google's guide to the attribute and the 2021 browser default change
• PortSwigger Web Security Academy — CSRF — interactive labs for hands-on practice