For a session cookie, use the __Host- prefix with Secure, HttpOnly, Path=/ and SameSite=Lax or Strict, and set no Domain attribute. That combination keeps the cookie on HTTPS, away from JavaScript, tied to one exact host and out of most cross-site requests.
The attributes, one by one
Based on MDN's cookie guide:
- Secure. Sent only over HTTPS. Insecure pages cannot set Secure cookies. It does not protect against someone with access to the disk, or against script if HttpOnly is missing.
- HttpOnly. JavaScript cannot read it through document.cookie. It limits the damage of XSS, though it does not stop XSS.
- SameSite. Controls cross-site sending. Strict sends only for requests from the cookie's own site. Lax also sends on top level navigation from another site. None sends on all cross-site requests and requires Secure. When unset, the cookie is treated as Lax.
- Domain. If omitted, the cookie goes only to the host that set it, which is the tighter choice. If set, subdomains receive it too.
- Path. Matches the path and below. MDN states it is not a security measure.
- Max-Age and Expires. Max-Age wins if both are set. Neither means a session cookie. Keep sensitive cookies short lived.
The prefixes
__Secure-requires the Secure attribute and an HTTPS page.__Host-requires Secure, an HTTPS page, no Domain attribute and Path=/. This pins the cookie to the exact host that set it.
One caveat from MDN: the server must check the full cookie name including the prefix, because browsers send it as is.
Set-Cookie: __Host-id=a3fWa; Secure; HttpOnly; Path=/; SameSite=Lax
A decision guide
- Login session: the example above. Use Strict if users do not arrive via links from other sites, otherwise Lax.
- Embedded widget that must work cross-site: SameSite=None with Secure, and accept that browsers increasingly block third-party cookies.
- Preference cookie: low risk, but still set Secure and a sensible lifetime.
- Anything sensitive: do not store data in the cookie. Store an opaque session ID and look the data up on the server.
Common mistakes
- Setting Domain to the parent domain, which hands the cookie to every subdomain, including forgotten ones. MDN notes that cookies set through a subdomain can be abused in session fixation.
- Not issuing a new session ID at login. Regenerate and resend the cookie on authentication so a pre-set session cannot be reused.
- Treating SameSite as a full CSRF defense. MDN says it provides some protection, so keep CSRF tokens for sensitive actions.
- Trusting cookie contents. Users can view and change cookies, so validate on the server.
More on this topic is in cookie security best practices and cookie security for modern web apps.
Where Safeguard fits
Safeguard does not manage this layer of your infrastructure. It scans the dependencies and SBOMs of the software you ship, uses reachability analysis to show which vulnerable code paths are actually used, and can enforce policies and gates in CI. A free scan is at gold.safeguard.sh/scan.
Quick check
Why prefer __Host- for session cookies?
It forces Secure, Path=/ and no Domain, so the cookie goes only to the exact host that set it and cannot be set from a subdomain.
Does HttpOnly stop XSS?
No. It stops scripts reading the cookie, which limits damage, but the XSS bug itself remains.
Sources
Last reviewed: 19 October 2026.
