Cookie Prefixes
Cookie prefixes — __Host- and __Secure- — make the browser enforce attributes: __Host- requires secure, no domain, and path slash; __Secure- requires the secure flag, blocking subdomain injection.
Definition
A cookie name beginning __Host- is accepted only when set on a secure connection, from the exact host without a Domain attribute, and with Path set to slash. __Secure- requires only the Secure attribute. These prefixes let applications guarantee that their cookies cannot be shadowed or overwritten by a compromised subdomain or plaintext path.
Context and scope
Applied to session and CSRF cookies on apex applications. Complements Secure, HttpOnly, and SameSite attributes rather than replacing them.
Common misconceptions
- Prefixes encrypt cookies — they are naming contracts that force the browser to validate attribute sets before storing
- The Secure attribute alone prevents subdomain injection — a non-Secure sibling subdomain can still set cookies that the browser later sends over secure requests
- __Secure- implies everything __Host- does — __Secure- only forces the Secure flag; __Host- also pins host and path
Anti-patterns
- Setting a __Host- cookie with a Domain attribute and watching browsers silently drop it in production only
- Leaving session cookies unprefixed on applications that also host untrusted user subdomains
- Assuming prefixes substitute for HttpOnly or SameSite rather than completing the set
Related concepts
Related examples
Authoritative source
What it is
Cookies are keyed by name, host, and path, and the most-specific match wins. An attacker controlling any subdomain can set a cookie with the same name scoped to the parent domain, shadowing your session. Prefixes weaponize the name: the browser refuses the cookie unless the declaration satisfies strict constraints.
How it works
A Set-Cookie for __Host-session is stored only if Secure is set, Domain is absent — pinning to the exact host — and Path is slash. This makes shadowing from sibling subdomains impossible for that name. __Secure- requires Secure only, suiting cookies that must be set with a Domain scope.
When to use it
Session, CSRF, and preference cookies on login-capable applications, especially platforms hosting user content on child domains. Roll out by renaming and reissuing with dual-read during migration.
Pitfalls
Prefixes are enforced by browsers only — intermediaries and non-browser clients may not validate. A misdeclared prefixed cookie is dropped silently, so integration tests must assert Set-Cookie is actually stored. Legacy browsers ignore prefixes and accept the cookie with weaker attributes.