Cookies and Sessions

1Why Cookies Exist

HTTP is stateless: every request is interpreted on its own, and the server has no built-in way to know that the request it is handling now came from the same client as the request a second ago. A cookie is the standard workaround — a small named value the server asks the client to store and then re-send automatically on every subsequent matching request.

# Response from the server
HTTP/1.1 200 OK
Set-Cookie: sid=a1b2c3; Path=/; HttpOnly

# Every later request the browser makes to that site
GET /account HTTP/1.1
Host: example.com
Cookie: sid=a1b2c3

Two headers do all the work: Set-Cookie (response, one cookie per header line) and Cookie (request, all matching cookies joined with ; ).

2Anatomy of Set-Cookie

Set-Cookie: sid=a1b2c3; Domain=example.com; Path=/app; Expires=Wed, 09 Sep 2026 10:00:00 GMT; Max-Age=86400; Secure; HttpOnly; SameSite=Lax

Note the asymmetry: attributes are only ever sent downward, in Set-Cookie. The Cookie header the browser sends back contains name/value pairs and nothing else — the server never sees which Path, Domain, or SameSite a returning cookie was stored under.

Cookie: sid=a1b2c3; theme=dark; lang=en

3Session Cookies vs Persistent Cookies

Set-Cookie: sid=a1b2c3; HttpOnly          # session cookie — dies with the browser session
Set-Cookie: theme=dark; Max-Age=31536000  # persistent — written to disk, survives restarts

A cookie with neither Expires nor Max-Age is a session cookie: it lives in memory and is discarded when the browsing session ends. Anything with a lifetime attribute is persistent and is stored on disk. (In practice, "restore my tabs on startup" features in browsers often revive session cookies too, so "dies with the browser" is a weaker guarantee than it sounds.)

To delete a cookie, you re-set the same name with an expiry in the past — there is no Delete-Cookie header:

Set-Cookie: sid=; Path=/; Max-Age=0

The Path (and Domain, if used) must match the original exactly, or you create a different cookie that happens to be empty and leave the real one in place.

4Server-Side Sessions vs Stateless Tokens

There are two mainstream ways to turn "the client holds a cookie" into "the server knows who this is".

Server-side session — the cookie holds an opaque random ID; all real state lives on the server.

// on login
const sid = crypto.randomUUID();
await store.set(sid, { userId: 42, roles: ["admin"] }, { ttlSeconds: 86400 });
res.setHeader("Set-Cookie", `sid=${sid}; Path=/; HttpOnly; Secure; SameSite=Lax`);

// on every request
const session = await store.get(parseCookies(req.headers.cookie).sid);
if (!session) return res.writeHead(401).end();

Stateless token — the cookie holds a signed payload (e.g. a JWT); the server verifies the signature and reads the claims, storing nothing.

Set-Cookie: token=eyJhbGciOi...<signature>; HttpOnly; Secure; SameSite=Lax

Revocation is the deciding factor far more often than performance: "log out all devices" and "ban this user right now" are cheap with a session store and awkward without one.

5Cookie Prefixes: __Host- and __Secure-

Set-Cookie: __Host-sid=a1b2; Path=/; Secure; HttpOnly; SameSite=Lax

These are not decoration — browsers enforce them at write time and reject the Set-Cookie otherwise:

• __Secure- requires the Secure attribute and an HTTPS origin.
• __Host- requires Secure, requires Path=/, and forbids Domain — which makes the cookie host-only and therefore impossible for a sibling subdomain to have written.

That last property is the point. Without it, a server receiving Cookie: sid=... cannot tell whether the cookie was set by itself or by a compromised blog.example.com that wrote Domain=example.com. A __Host- prefix makes the name itself a proof of provenance.

6SameSite in Practice

Lax is the modern default in major browsers when the attribute is absent. Strict breaks the common "click a link in an email to a logged-in page" flow (the user arrives logged out), which is why Lax is the usual choice for a session cookie, with Strict reserved for high-value cookies where that friction is acceptable.

SameSite=None without Secure is rejected outright — a cookie cannot opt into cross-site sending over plaintext.

# Set by https://app.example.com
Set-Cookie: a=1                      -> host-only: sent ONLY to app.example.com
Set-Cookie: b=2; Domain=example.com  -> sent to example.com AND every subdomain

Set-Cookie: sid=A; Domain=example.com; Path=/
Set-Cookie: sid=B; Path=/
Set-Cookie: sid=C; Path=/app

Cookie: sid=C; sid=B; sid=A

⚠️ Common Pitfalls

1. Trying to delete a cookie without matching Path/Domain. Set-Cookie: sid=; Max-Age=0 from /api deletes the /api-scoped sid, not the /-scoped one; the key is the triple, so a mismatched attribute creates or clears a different cookie and the real one survives untouched.
2. Using Domain=example.com "to be safe". It widens the cookie to every subdomain, handing your session ID to any host under that domain — including ones you do not control. Omit Domain unless you genuinely need cross-subdomain sharing.
3. Assuming HttpOnly stops XSS. It stops exfiltration of the value; the injected script can still make authenticated requests from the victim's browser. Treat HttpOnly as damage limitation, not as a reason to skip output escaping and CSP.
4. SameSite=None without Secure. The browser rejects the entire Set-Cookie. The symptom is not an error — the cookie simply never appears, and login "randomly doesn't work" in whichever flow needs it.
5. Storing anything meaningful in the cookie value in a server-side-session design. If the cookie carries userId=42 rather than an opaque random ID, the client can edit it. The ID must be unguessable and carry no data; the data belongs in the store.
6. Not rotating the session ID on privilege change. If the pre-login and post-login session ID are the same value, an attacker who can plant a known ID in the victim's jar (session fixation) is logged in as them once they authenticate. Issue a fresh ID at login and discard the old one.
7. Forgetting the ~4 KB per-cookie limit and ~50-cookies-per-domain browser caps. Oversized cookies are dropped silently, and blowing the count evicts other cookies — including the session one. This is a common failure when JWTs with many claims are stored in cookies.
8. Treating multiple Set-Cookie headers as comma-joinable. Expires contains a comma, so naive joining corrupts them; use the dedicated multi-value accessor (see networking-web/http/03-http_headers).

📋 Quick Reference

Set-Cookie: name=value; Domain=; Path=; Expires=; Max-Age=; Secure; HttpOnly; SameSite=
Cookie: name=value; name2=value2          <- attributes are NOT echoed back

Max-Age wins over Expires
No Expires/Max-Age        -> session cookie (memory only)
Max-Age=0 / past Expires  -> delete (Path+Domain must match exactly)

Domain omitted   -> host-only, exact hostname match      <- the safe default
Domain=parent    -> WIDENS to parent + all subdomains
Domain=<public suffix> -> rejected by the browser

HttpOnly  -> not in document.cookie; XSS can't READ it (can still USE it)
Secure    -> HTTPS only when sending
SameSite=Strict -> never cross-site        Lax -> top-level GET only (default)
SameSite=None   -> cross-site allowed, REQUIRES Secure

__Secure-name -> requires Secure
__Host-name   -> requires Secure + Path=/ + NO Domain (host-only, unforgeable)

jar key = (domain, path, name)   -> same name can exist 3x and shadow itself

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: http_cookies_and_sessions_theory.md · generated by tools/build_lessons.py