A cookie name prefix is a rule the browser enforces. __Secure- requires the Secure attribute and an HTTPS page. __Host- requires all that plus no Domain attribute and a Path of /, which pins the cookie to the exact host that set it. Session cookies are good candidates.
The rules
From MDN's cookie documentation:
__Secure-: the name must start with __Secure-, and the cookie must be set with Secure by an HTTPS page.
__Host-: the name must start with __Host-, be set with Secure by an HTTPS page, have no Domain attribute, and use Path=/. The effect is that the cookie is sent only to the host that set it, not to other hosts on the domain.
Browsers reject prefixed cookies that do not meet the restrictions. One detail for server developers: user agents do not strip the prefix before sending the cookie, so the server must look for the full name, including the prefix.
Why this matters
Without a prefix, a cookie's guarantees depend on what the setting site chose. MDN explains that if Domain is specified, the cookie is available on that server and all its subdomains, while omitting it keeps it to the setting server. A cookie set with a parent Domain can therefore be read by, and potentially overwritten from, a sibling subdomain that you may not control.
The __Host- prefix rules those cases out for that cookie, because the browser will refuse it if it has a Domain attribute. The OWASP Session Management Cheat Sheet recommends __Host- for session cookies, along with leaving Domain unset and keeping Path as restrictive as possible.
A good session cookie
Set-Cookie: __Host-sid=<value>; Secure; HttpOnly; SameSite=Lax; Path=/
Each part has a job. Secure keeps it off plain HTTP. HttpOnly stops page scripts reading it, which helps mitigate XSS theft. SameSite limits cross-site sending; MDN says that without the attribute a cookie is treated as Lax, but OWASP advises setting Strict or Lax explicitly and treats it as defense in depth, not a replacement for CSRF tokens. The prefix makes the browser enforce the host-only, HTTPS-only parts.
Note that __Host- needs Path=/, so you cannot use path restriction to narrow it. The trade is host-only scope in exchange.
How to adopt it
- Make sure the whole site is served over HTTPS first. A prefixed cookie cannot be set from HTTP.
- Rename the cookie in your session library, and update every place that reads the name.
- Remove any Domain attribute from the session cookie settings.
- Deploy with a migration plan: accept the old name for a short period so users are not logged out all at once, then retire it and expire the old cookie by sending it again with
Max-Age=0. - Test in several browsers, and test the logout flow, since deleting a cookie needs the same name, path and domain.
When it does not fit
If you need one session across several subdomains, __Host- is the wrong tool because it forbids Domain. Consider whether those apps should share a session at all; separate hosts with separate sessions are simpler to secure. A __Secure- cookie with a Domain is the fallback, with the risks above.
For more on server-side session rules, see session timeouts and logout.
Quick check
Does a prefix replace HttpOnly or SameSite?
No. The prefixes add rules about Secure, Domain and Path. You still set HttpOnly and SameSite yourself.
Can JavaScript read a __Host- cookie?
Yes, unless it is also HttpOnly. The prefix does not hide it from scripts.
Sources
Last reviewed: 19 October 2026.
