Set-Cookie builder
Most session compromises are cookie problems, not header problems. Compose the
Set-Cookie response header attribute by attribute, see what each one gives
away, and catch the combinations a browser will silently refuse to store.
Name & value
Protection
Scope & lifetime
The short version
A session cookie wants four things: Secure, HttpOnly,
SameSite=Lax (or Strict), and the __Host- prefix.
The prefix is the one browsers enforce for you — a __Host- cookie is
rejected unless it is Secure, has Path=/, and sets no
Domain, which is exactly what stops a compromised subdomain from
overwriting your session.
Everything else is scope: omit Domain so the cookie stays host-only, and
keep the lifetime short enough that a stolen cookie stops working.
About cookie attributes
A cookie is just a name, a value, and a handful of attributes — but those attributes decide
whether a stolen laptop on café Wi-Fi, an XSS payload, or a neglected subdomain turns into a
hijacked session. Three of them do most of the work: Secure keeps the cookie off
plaintext HTTP, HttpOnly keeps it out of reach of injected JavaScript, and
SameSite keeps it off cross-site requests so an attacker's page cannot ride your
user's session. The
MDN reference
lists them all; securityheaders.fyi
covers how they fit alongside the rest of your response headers.
Let the browser enforce it
The __Host- prefix turns your intentions into rules the browser checks:
Secure, Path=/, and no Domain, or the cookie is
not stored at all.
Scope down, not out
Omit Domain so the cookie stays host-only. A wildcard cookie is only as
safe as the weakest subdomain that can read it.
Short lives, server-side truth
Expiry in the cookie is a hint the client can ignore. Keep Max-Age short
and revoke the session server-side — that's the part an attacker cannot skip.