On a session cookie, check Secure, HttpOnly and an intentional SameSite value. Prefer the __Host- prefix, avoid a broad Domain attribute, and confirm the session ID is regenerated when a user logs in. These come from the MDN cookie guide.
The flags
| Flag | What MDN says it does | Review note |
|---|---|---|
| Secure | Cookie is sent only over HTTPS | Expected on every session cookie |
| HttpOnly | Not accessible to JavaScript, so it mitigates XSS cookie theft | Session cookies should have it |
| SameSite Strict | Sent only for requests from the cookie's site | Strictest option. May disrupt links arriving from other sites |
| SameSite Lax | Also sent on navigation from another site | The default when no attribute is set |
| SameSite None | Sent on cross-site requests, requires Secure | Needs a reason, such as an embedded service |
Secure does not stop client side access: anyone with disk access, or script when HttpOnly is missing, can read the value.
Scope: Domain and Path
If Domain is omitted, the cookie goes only to the host that set it. Setting Domain, for example to a parent domain, includes subdomains and is less restrictive. In review, a new Domain attribute should prompt a question: does every subdomain deserve to see this cookie? A forgotten or compromised subdomain becomes a path to the session.
MDN notes that Path is not a security boundary and does not protect against reading from another path.
The __Host- prefix
A cookie named with the __Host- prefix must be set with Secure by an HTTPS page, must not have a Domain attribute, and must have Path set to a slash. The result is a cookie sent only to the host that set it. Browsers reject prefixed cookies that break the rules. MDN adds a subtle point: servers must check the full name including the prefix, since browsers do not strip it.
Set-Cookie: __Host-session=opaque-random-id; Secure; HttpOnly; SameSite=Lax; Path=/
Lifetime and fixation
Session cookies have no Max-Age or Expires and are deleted when the browser session ends, though session restore can make them last indefinitely. MDN advises regenerating and resending session cookies whenever a user authenticates, to prevent session fixation, keeping sensitive cookies short lived, and preferring an opaque session ID that the server looks up over storing sensitive data in the cookie.
Steps for a review
- Find where cookies are set: the framework session config and any manual header writes.
- Check each flag in the table.
- Check whether the login handler issues a new session ID.
- Check whether the cookie holds data, or only an opaque ID.
- If SameSite is None or Domain is broad, ask for the reason in the pull request.
Pair it with CSRF review
SameSite is a helpful layer, not a full defense against cross-site request forgery. The related OWASP CSRF guidance treats it as defense in depth, so review token or header protection on state changing routes at the same time.
Where Safeguard fits
Safeguard scans dependencies and builds SBOMs, including session and framework libraries. Try the free scan at gold.safeguard.sh/scan.
Quick check
What is the default SameSite value?
Per MDN, a cookie without a SameSite attribute is treated as Lax.
Does HttpOnly stop all cookie theft?
No. It blocks script access, which mitigates XSS cookie theft, but it does not stop other routes to the value, such as disk access.
Sources
Last reviewed: 19 October 2026.
