Glossary
HTTP cookie
A cookie is a small name-and-value pair a server asks a browser to store and send back on subsequent requests to the same site. It is the mechanism that makes HTTP stateful: without it, every request would be anonymous and unrelated to the last. What a cookie can do is almost entirely decided by its attributes — which hosts receive it, over which protocol, for how long, and whether scripts can read it.
How one is set and returned
The server sends a `Set-Cookie` response header containing the name, the value and any attributes.
The browser stores it and attaches it, as a `Cookie` request header, to every subsequent request that matches the cookie's domain, path and security constraints.
The value is opaque to the browser. It may be an identifier pointing at server-side state, or it may carry the state itself, in which case its integrity has to be protected by a signature.
A browser enforces limits — roughly 4 KB per cookie and a few dozen per domain — and silently drops what exceeds them, which is how a large cookie causes a bug that appears only for some users.
The attributes that decide scope
`Domain` widens the scope from the exact host that set it to that domain and all its subdomains. Omitting it is narrower and usually safer.
`Path` restricts the cookie to a path prefix. It is not a security boundary, because any page on the host can read cookies through script regardless of path.
`Expires` and `Max-Age` make the cookie persistent. Without either, it is a session cookie and is discarded when the browser session ends — though browsers that restore sessions restore these too.
`Secure` restricts it to HTTPS. `HttpOnly` hides it from `document.cookie`. `SameSite` controls whether it accompanies cross-site requests.
The `__Secure-` and `__Host-` name prefixes let the browser enforce these: a cookie named with `__Host-` is rejected unless it is `Secure`, has path `/`, and carries no `Domain`.
Session cookies and persistent cookies
A session cookie lasts for the browsing session. It is the right shape for a login session, because it disappears when the browser does.
A persistent cookie survives restarts until its expiry, which is what makes a stay-signed-in option work and what makes long-lived tracking possible.
Browsers now cap how long a cookie set by script may persist — in some cases to seven days — which breaks assumptions in code that sets a year-long preference from JavaScript.
A very long expiry on an authentication cookie is a decision about how long a stolen cookie remains useful, and it is worth making deliberately rather than by default.
How to see the cookies a site sets
`curl -I https://example.com | grep -i set-cookie` shows what an anonymous first request receives, with every attribute.
The browser's Application panel lists every stored cookie with columns for each attribute, which is the fastest complete view.
`document.cookie` in the console returns only the cookies readable by script. Anything absent from that list is `HttpOnly`, and a session identifier appearing in it is a finding.
Check after logging in as well as before. The session cookie is set at authentication and is the one whose attributes matter most.
Frequently asked questions
- What is the difference between a session cookie and a persistent one?
- A session cookie is discarded when the browser session ends. A persistent cookie carries an expiry and survives restarts until it is reached.
- Is the Path attribute a security boundary?
- No. Any page on the same host can read cookies through script regardless of path, so it organises rather than protects.
- What does the __Host- prefix do?
- It makes the browser enforce the attributes: a cookie with that prefix is rejected unless it is Secure, has path /, and has no Domain attribute.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website