HTTP is stateless, so cookies and server-side sessions are the classic mechanism for remembering who a client is across requests. Their attributes are also one of the highest-leverage areas for web security interview questions, since a misconfigured cookie is a direct path to session hijacking or CSRF.
A cookie is a small piece of text a website asks your browser to store, then hands back to that same site on every later visit. Sites use this to remember things about you between page loads — since a web server normally forgets you the instant it finishes answering one request, the cookie is what lets it recognize you again a minute, or a month, later.
A session is the actual record of who you are and what you're doing, kept on the server, not in the cookie itself. The cookie just carries a short ID number pointing at that record — so if someone steals the cookie, they get a pointer to your session, not your password or personal details directly.
Think of checking into a hotel. At the front desk you hand over ID once, and in return you get a room key card with no name or account number printed on it — just a code. Every door in the building reads that code and looks up, in the hotel's own system, who you are and what you're allowed to access. Lose the card and a stranger can open your door, but they still can't see your actual identity just from holding it — the hotel's internal records are what matter.
POST /login HTTP/1.1
Host: app.example.com
Content-Type: application/json
{"email":"[email protected]","password":"••••••••"}
HTTP/1.1 200 OK
Set-Cookie: session_id=8f3ac1b2e9; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=604800
--- every subsequent request from this browser to app.example.com ---
GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session_id=8f3ac1b2e9The server never trusts anything about the client's identity beyond that opaque session_id. On every request it looks the ID up in a session store (in-memory, Redis, or a database) to find the actual user record, role, and any other session state. The cookie itself carries no meaningful data — that's the point: if it's stolen, an attacker gets a session ID they can replay, not the user's password or any directly readable identity claim.
HttpOnly — makes the cookie invisible to document.cookie in JavaScript. This directly mitigates token theft via XSS: even if an attacker gets a script running on your page, they can't read and exfiltrate the session cookie.Secure — the browser will only ever send this cookie over an HTTPS connection, never plain HTTP. Without it, a session cookie can leak in plaintext to anyone on the same network path if the user ever hits an http:// URL for that domain.SameSite=Strict — the cookie is never sent on cross-site requests, including a user clicking a link from another site into yours. Most secure, but can break legitimate cross-site navigation flows (e.g. arriving from an external link while relying on being logged in).SameSite=Lax (the modern browser default) — the cookie is sent on top-level navigations (clicking a link) but not on cross-site subrequests like an <img> or a background fetch from another origin — this is what blocks the classic CSRF pattern of a malicious site silently firing a background request against your session.SameSite=None — sent on all cross-site requests; requires Secure to be set alongside it. Needed for legitimate cross-site embedding (e.g. a widget on a third-party site), but reopens the CSRF surface that Lax/Strict close, so it needs its own CSRF token defense.Set-Cookie response header; the browser automatically attaches it on subsequent matching requests via the Cookie header.HttpOnly (blocks JavaScript access, mitigating token theft via XSS), Secure (only sent over HTTPS), SameSite=Strict/Lax/None (controls cross-site sending, mitigating CSRF), plus Domain/Path (scope) and Max-Age/Expires (lifetime).Set-Cookie carrying the session ID (or token), with HttpOnly/Secure/SameSite set appropriately.Cookie header on future requests to the matching origin.Max-Age/Expires or explicit server-side invalidation — logout deletes the session record.# Capture the Set-Cookie header from a login response
curl -v -X POST https://app.example.com/login \
-H "Content-Type: application/json" \
-d '{"email":"[email protected]","password":"secret"}' \
-c cookies.txt
# Reuse the saved cookie jar on a follow-up authenticated request
curl -v -b cookies.txt https://app.example.com/dashboard
# In Chrome DevTools: Application tab → Storage → Cookies → pick the domain
# shows every cookie's Name, Value, Domain, Path, Expires, HttpOnly, Secure, SameSite
# Try to read a cookie from the console to confirm HttpOnly is working
# (run in DevTools Console on the target site)
document.cookie // HttpOnly cookies will NOT appear in this outputQ: Why store just a session ID in the cookie instead of the user's actual data?
A: It minimizes the blast radius of a stolen cookie and keeps the cookie small (there's a practical ~4KB cap per cookie). If the ID alone leaks, an attacker gets a replayable session, not directly readable user data — and because the real state lives server-side, you can revoke it instantly by deleting the session record, which you can't do with data embedded directly in a client-held token.
Q: How does SameSite=Lax mitigate CSRF, specifically?
A: CSRF works by getting a victim's browser to fire a request to a site they're authenticated on, from a page they didn't intend to interact with that site — e.g. an <img src="https://bank.example.com/transfer?to=attacker&amount=1000"> embedded on a malicious page. With SameSite=Lax, the browser won't attach the session cookie to that background cross-site request at all, so the request arrives unauthenticated and the server rejects it. It still allows the cookie on top-level navigation (a user clicking a normal link into your site), which is what makes Lax the practical default instead of Strict.
Q: What's the trade-off between server-side sessions and stateless tokens for scaling?
A: Server-side sessions are trivially revocable — delete the record and the user is logged out everywhere immediately — but every request needs a lookup against a shared store, which becomes a scaling and availability dependency once you have more than one server instance. Stateless tokens (like a JWT) remove that lookup — any instance can verify the signature locally — but revocation before natural expiry is hard; you either accept it can't happen instantly, or you reintroduce state via a denylist, which gives back some of the scaling benefit you were trying to gain.
Q: If HttpOnly stops JavaScript from reading the cookie, does that mean XSS is no longer a risk for a site using cookie-based auth?
A: No — it stops one specific attack (exfiltrating the raw session token), not XSS itself. An attacker with script execution on your page can still make authenticated requests on the victim's behalf using the browser's ambient cookie — they just can't steal the cookie value to replay it elsewhere later. HttpOnly narrows the damage; it doesn't neutralize XSS as a threat.
Cookie/session design comes up directly whenever you're asked to design authentication for a web app, and it's one of the few areas where interviewers expect exact header names, not just concepts. For a multi-instance backend, be ready to say you'd back sessions with Redis (shared, fast, supports TTL-based expiry natively) rather than in-process memory, since in-process sessions break the moment a load balancer routes a user's next request to a different instance. For a system spanning multiple subdomains (app.example.com, api.example.com), the Domain attribute decision matters — setting Domain=.example.com shares the cookie across subdomains but also widens the blast radius if any one subdomain is compromised. For a public API consumed by third-party clients (mobile apps, other backends) rather than a browser-hosted frontend, token-based auth in an Authorization header is usually preferred over cookies, since cookies are a browser-specific mechanism.
Server-side sessions are trivially revocable — delete the record and the user is logged out everywhere instantly — but require a shared, stateful store and a lookup on every request. Stateless cookie-stored tokens scale without that shared store but are hard to revoke before they expire and put more of the security burden on the token itself. The interview pitfall to watch for: forgetting SameSite/CSRF protection on cookie-based auth, since browsers attach cookies automatically even to cross-site requests unless SameSite restricts it — that gap is exactly what CSRF exploits.