Safety
__Host- vs __Secure- Cookie Prefixes for Session OPSEC
February 15, 2024
__Host- vs __Secure- cookie prefixes is how you stop a weaker Set-Cookie from impersonating your session name. Browsers that honor prefixes refuse to store __Secure- unless Secure is set, and refuse __Host- unless Secure is set, Path is /, and Domain is omitted so the cookie is host-only. Plain session= with HttpOnly and SameSite is still good; prefixes add a name-level lock so a subdomain or a sloppy CDN cannot quietly replace the vault key. RoastMyOpsec grades Set-Cookie on the landing response, including prefix-shaped names. It does not log in or overwrite cookies in your browser.
The practical difference
Cookie flags are attributes on this response. A later response on a sibling host can still try to set the same cookie name with weaker rules if the name is unprotected. Prefixes make the name itself a contract the browser enforces.
__Secure- is the lighter contract: HTTPS only. __Host- is the stricter one: HTTPS, host-only, path /. Most app session cookies that already live on one origin want __Host-. CDN cookies that must be shared across www and a shop host cannot use __Host-; they may use __Secure- plus a careful Domain — or, better, stop sharing the session cookie across hosts.
How to choose based on the cookie's job
If the cookie proves login on a single origin (app.example.com or www only), name it __Host-session (or similar), set Path=/, omit Domain, and keep HttpOnly plus SameSite. If marketing must share a preference cookie across subdomains, do not reuse the session name; use a different cookie and never prefix a cross-subdomain session as __Host- — the browser will reject it.
| Name shape | Browser requires | Typical use | Takeaway |
|---|---|---|---|
| session (no prefix) | Whatever you set | Legacy apps | Flags still matter; name can be spoofed by a weaker setter |
| __Secure-session | Secure flag | HTTPS cookies that may set Domain | Better than naked names; still not host-only |
| __Host-session | Secure, Path=/, no Domain | Single-origin session | Default for new auth cookies on HTTPS |
| __Host- on a shared Domain | Rejected | Mistake | Split hosts or drop __Host- |
What a public scan can prove
If the landing Set-Cookie already uses __Host- or __Secure-, the roast can score that name. Cookies issued only after login stay invisible, same as other session flags. Pair this with the HttpOnly / Secure / SameSite guide: prefixes do not replace those flags; they make Secure (and host scope) harder to forget.
Common mistakes
The first mistake is __Host- plus Domain=.example.com, which browsers drop.
The second mistake is a prefix on the session and a duplicate unprefixed copy 'for the SPA.'
The third mistake is assuming a URL roast saw the login cookie when only a marketing cookie was on the homepage.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is __Host- better than __Secure-?
- For a session that should never leave one host, yes. __Host- is stricter. Use __Secure- only when you have a documented need to set Domain on an HTTPS cookie.
- Do prefixes replace HttpOnly and SameSite?
- No. Prefixes constrain Secure, Path, and Domain. Still set HttpOnly and SameSite=Lax or Strict on auth cookies.
- Will RoastMyOpsec fail me for a plain session name?
- Missing prefixes is a hardening hint, not the same as a missing Secure flag. The scan grades what Set-Cookie actually sent on the audited URL.