Cookies
Introduction
Cookies are small name-value strings stored by the browser and automatically sent with matching HTTP requests. Unlike localStorage and sessionStorage, cookies are part of the HTTP request/response model, not just client-side state.
For interviews, cookies matter most for authentication and security flags: HttpOnly, Secure, and SameSite.
Why This Matters
Cookie knowledge is where frontend and backend security meet. A candidate who can explain why HttpOnly helps against token theft, why SameSite helps against CSRF, and why cookies are size-limited is operating above syntax-level JavaScript.
Theory
What a cookie is
A cookie is a small string associated with a domain/path and optional metadata. Servers set cookies with the Set-Cookie response header. Browsers send matching cookies back in the Cookie request header.
JavaScript can read and write non-HttpOnly cookies through document.cookie, but the API is awkward: it exposes cookies as a semicolon-separated string and writes one cookie at a time.
Cookie attributes
| Attribute | Purpose |
|---|---|
Expires or Max-Age | Controls lifetime |
Domain | Which hosts can receive the cookie |
Path | Which URL paths receive the cookie |
Secure | Send only over HTTPS |
HttpOnly | Hide from JavaScript; server-set only |
SameSite | Control cross-site sending behavior |
SameSite in interviews
SameSite=Strict sends cookies only for same-site navigations. Lax is a practical default that allows some top-level navigations while blocking many cross-site subrequests. None allows cross-site usage but must be paired with Secure.
Cookies vs web storage
| Feature | localStorage | sessionStorage | Cookies |
|---|---|---|---|
| Typical capacity | Megabytes | Megabytes | About 4 KB per cookie |
| Expiry | Manual clear | Tab/session end | Expiry, max-age, or session |
| Scope | Origin | Origin plus tab | Domain and path |
| Sent to server | No | No | Yes, automatically |
| JavaScript access | Yes | Yes | Only if not HttpOnly |
| API style | Synchronous key-value | Synchronous key-value | Headers and document.cookie string |
Security notes
For session identifiers, prefer server-set cookies with HttpOnly, Secure, and an appropriate SameSite value. HttpOnly prevents JavaScript from reading the cookie after XSS, though XSS can still perform actions as the user while it runs. Secure requires HTTPS. SameSite reduces CSRF risk but does not replace CSRF tokens for every architecture.
Visual Diagrams
Server response Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax | v Browser stores cookie | v Later matching request Cookie: session=abc | v Server reads session id
Cookies are automatically attached to matching HTTP requests, which is the key difference from web storage.
HttpOnly JavaScript cannot read the cookie Secure browser sends only over HTTPS SameSite controls cross-site cookie sending
The important interview answer is how each flag changes attacker options.
Code Examples
Read a non-HttpOnly cookie by name
This works only for cookies visible to JavaScript. HttpOnly cookies are intentionally hidden.
Write and delete a JavaScript-visible cookie
Client-side code cannot set HttpOnly; that flag must come from the server's Set-Cookie header.
Server-set session cookie shape
This is the kind of header you want for many session identifiers. It is shown as a string because the exact server framework varies.
Coding Exercises
Build a safe Set-Cookie header string
MediumImplement buildCookie(name, value, maxAgeSeconds) that returns a cookie header string with encoded name/value and the attributes HttpOnly, Secure, SameSite=Lax, Path=/, and Max-Age=<seconds>.
Interview Questions
1How are cookies different from `localStorage`?
Cookies are automatically sent with matching HTTP requests and are controlled by domain/path and security attributes. localStorage is an origin-scoped client-side string store and is not sent to the server. Cookies are much smaller but can be HttpOnly, which hides them from JavaScript.
2What do `HttpOnly`, `Secure`, and `SameSite` do?
HttpOnly prevents JavaScript from reading the cookie. Secure sends it only over HTTPS. SameSite controls whether the browser sends it on cross-site requests, reducing CSRF risk depending on the selected mode.
Follow-ups
- Can JavaScript set `HttpOnly`?
- Why must `SameSite=None` use `Secure`?
Quiz
1. Which cookie attribute prevents JavaScript from reading a cookie?
2. Which browser storage mechanism is automatically sent to the server on matching requests?
Summary
- Cookies are small strings that can be sent automatically with HTTP requests.
- Servers set cookies with `Set-Cookie`; browsers send them back in `Cookie` headers.
- `HttpOnly`, `Secure`, and `SameSite` are central security attributes.
- Use cookies for server/session metadata, not large client-only application state.
Cheat Sheet
Set by server: Set-Cookie response header.
Sent by browser: Cookie request header for matching domain/path.
Client API: document.cookie only for non-HttpOnly cookies.
Security: HttpOnly hides from JS, Secure requires HTTPS, SameSite limits cross-site sending.
Size: small; roughly 4 KB per cookie.
Use case: sessions, server-readable preferences, request metadata.