Every knob on a Set-Cookie
The Set-Cookie response header carries a name/value pair plus attributes that
control the cookie’s scope, lifetime and security posture. Getting these right
is the difference between a hardened session token and a hijackable one. This
reference lists every standard attribute with its behaviour and security
implications, searchable by name.
How it works
A cookie is set with Set-Cookie and returned by the browser in the Cookie
request header for matching requests. Attributes after the first ; shape
where and when it is sent:
Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
Domain and Path set the scope; Expires/Max-Age set lifetime; Secure
and HttpOnly restrict transport and script access; SameSite governs
cross-site sending; Partitioned opts into CHIPS partitioned storage. Name
prefixes __Secure- and __Host- add browser-enforced requirements.
Tips and notes
- Session cookies (no Expires/Max-Age) are cleared when the browser session ends.
- Always combine
HttpOnly+Secure+SameSiteon auth cookies. - Use the
__Host-prefix to pin a cookie to one exact host and path/. - Omitting
Domainscopes the cookie to the exact host — usually what you want. Partitioned(CHIPS) keeps a cross-site cookie in a per-top-site jar, surviving third-party cookie phase-out.