How Do Cookies Work Over HTTP?
Learn how HTTP cookies work — Set-Cookie, Cookie headers, session management, and security attributes like HttpOnly and SameSite.
Expected Interview Answer
A cookie is a small piece of state a server asks a browser to store via the `Set-Cookie` response header, which the browser then automatically re-attaches on the `Cookie` request header for subsequent requests to that same site — turning stateless HTTP into something that can track sessions, login state, and preferences.
HTTP itself has no memory between requests, so cookies exist to bridge that gap: after a login, the server sends `Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax`, and every later request from that browser to the same domain automatically includes `Cookie: sessionId=abc123`, letting the server recognize the same user. Attributes control scope and safety: `Domain`/`Path` limit which requests receive the cookie, `Expires`/`Max-Age` control lifetime, `Secure` restricts it to HTTPS, `HttpOnly` blocks JavaScript access to reduce XSS risk, and `SameSite` restricts cross-site sending to reduce CSRF risk. Because cookies are sent automatically and implicitly by the browser, they are the classic mechanism behind session management, and their implicit-credential nature is exactly why CSRF attacks exist and why `SameSite` was introduced. Modern alternatives like token-based auth in an `Authorization` header avoid some of these implicit-sending risks but lose the browser’s automatic attachment convenience.
- Adds persistent state on top of stateless HTTP requests
- Enables session/login persistence across page loads
- Attributes (HttpOnly, Secure, SameSite) provide security controls
- Automatically attached by the browser without app code re-sending it
AI Mentor Explanation
A cookie is like a wristband a gate steward hands a spectator on entry, which the spectator then shows automatically at every stand they walk into for the rest of the day instead of buying a fresh ticket each time. The wristband’s color can restrict which stands it grants access to, just as a cookie’s `Domain` and `Path` restrict where it is sent. If the wristband is stolen, whoever wears it gets treated as that spectator — which is exactly why cookies need protections like `Secure` and `HttpOnly`. The steward reading the wristband each time mirrors a server reading the `Cookie` header on each request.
Step-by-Step Explanation
Step 1
Server sets the cookie
Response includes `Set-Cookie: name=value` with attributes like `Expires`, `Secure`, `HttpOnly`, `SameSite`.
Step 2
Browser stores it
The browser saves the cookie scoped to the issuing domain and path.
Step 3
Browser re-attaches it automatically
Every matching subsequent request includes `Cookie: name=value` without app code re-sending it.
Step 4
Server reads it per request
The server looks up session/user state associated with the cookie value on each incoming request.
What Interviewer Expects
- Explains Set-Cookie / Cookie header round trip clearly
- Names key attributes: HttpOnly, Secure, SameSite, Expires/Max-Age
- Connects cookies to session management and stateless HTTP
- Understands why cookies enable CSRF and how SameSite mitigates it
Common Mistakes
- Confusing cookies with browser localStorage/sessionStorage (cookies are auto-sent with requests, storage APIs are not)
- Forgetting HttpOnly blocks JavaScript access but does not prevent the browser from sending the cookie over HTTP
- Not knowing SameSite controls cross-site sending, which is central to CSRF defense
- Assuming all cookies are session cookies (persistent cookies survive browser restarts via Expires/Max-Age)
Best Answer (HR Friendly)
“A cookie is a small piece of data a website asks your browser to remember, like a login session, so you do not have to sign in again on every single page. The browser automatically sends it back to the site with future requests, which is what lets sites keep you logged in, remember your cart, or track preferences.”
Code Example
# Login request returns a Set-Cookie header
curl -v -c cookies.txt -d "user=demo&pass=demo" https://example.com/login
# Look for:
# < Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax
# Reuse the saved cookie jar on a follow-up request
curl -v -b cookies.txt https://example.com/dashboard
# > Cookie: sessionId=abc123Follow-up Questions
- What is the difference between a session cookie and a persistent cookie?
- How does the SameSite attribute help prevent CSRF attacks?
- Why does HttpOnly reduce (but not eliminate) XSS risk?
- How do third-party cookies differ from first-party cookies, and why are browsers restricting them?
MCQ Practice
1. Which header does a server use to set a cookie in the browser?
The server sends `Set-Cookie` in the response; the browser echoes it back via the `Cookie` request header afterward.
2. What does the HttpOnly cookie attribute do?
HttpOnly prevents client-side JavaScript from accessing the cookie, reducing the impact of XSS attacks.
3. What security problem does the SameSite attribute primarily address?
SameSite restricts when a cookie is sent on cross-site requests, mitigating CSRF attacks.
Flash Cards
How is a cookie set? — Server response header `Set-Cookie: name=value` with optional attributes.
How is a cookie sent back? — The browser automatically includes it in the `Cookie` request header on matching requests.
What does HttpOnly do? — Blocks JavaScript from reading the cookie, reducing XSS impact.
What does SameSite do? — Restricts cross-site sending of the cookie, mitigating CSRF attacks.