Cookies and Their Attributes

Cookie attributes are not a style checklist; each one exists because of a concrete attack, and knowing which attack tells you when an attribute is negotiable and when it is not.

`Secure` — send only over HTTPS. Without it a single plaintext request to the domain (a typed URL, an old bookmark, a hardcoded http:// link, an image) transmits the session id in the clear. Non-negotiable.

`HttpOnly` — hide the cookie from JavaScript. This is depth against XSS: an injected script can still *act* as the user by making requests, but it cannot read the token and send it somewhere for later use. It converts an unbounded compromise into one that lasts only as long as the script runs. Non-negotiable for session cookies.

`SameSite` — control whether the browser attaches the cookie to cross-site requests. Strict withholds it on every cross-site request, including top-level navigation, so following a link from an email lands you logged out. Lax withholds it on cross-site subresource requests and form POSTs but keeps it for top-level GET navigation, which is the usual right default. None sends it always and requires Secure; it is needed for genuine third-party embedding and removes the protection.

`Domain` — which hosts receive the cookie. Setting Domain=example.com sends it to every subdomain, including blog.example.com running unmaintained software and preview-x.example.com created by a build system. Omit Domain entirely to scope it to the exact host, which is what you want unless you specifically need sharing.

`Path` and lifetime — narrower is better, though Path is weak isolation since same-origin scripts can read across paths. A session cookie without Max-Age/Expires ends with the browser session, which is a reasonable default for high-value applications.

Cookie scoping does not follow the same-origin policy, and this asymmetry is the source of a whole family of incidents. A cookie set with Domain=example.com is sent to every subdomain. Worse, a cookie *set by* any subdomain can be scoped to the parent domain, which means blog.example.com can write a cookie that app.example.com will receive.

That gives a compromised or merely careless subdomain two capabilities. It can read your session cookie if the cookie is domain-scoped — so an XSS on a marketing page reaches the application session. And it can write a cookie with the same name, which the application may accept, enabling session fixation from a host you do not think of as part of the application.

The defenses are specific. Omit Domain so cookies are host-only. Use the __Host- prefix for session cookies, which makes the browser refuse the cookie unless it is Secure, Path=/ and host-only — so no subdomain can overwrite it. Keep user-generated content and third-party-managed sites on a completely separate registrable domain, not a subdomain, so the cookie boundary and the trust boundary coincide.

Every attribute here is an instruction to a cooperating browser. A non-browser client — a script, a proxy, an attacker with the cookie value copied out of a log — ignores all of them. HttpOnly does not stop an attacker who already has the value; Max-Age does not stop a cookie whose value was saved last month.

So the server must enforce the properties it actually cares about independently. Expiry must be checked server-side against the session record, because a client that keeps sending an expired cookie is a client, not an error. Revocation must delete server state, because there is no way to make a browser forget a value it has already exfiltrated. And the session id must be rotated on privilege change, because attributes cannot express "this cookie is no longer the right one".

The attributes reduce the ways a cookie *escapes*; the server-side session record is what limits what an escaped cookie can do. Both halves are required, and teams that set the attributes carefully and then implement expiry only in Max-Age have built the first half twice.