Cybersecurity glossary
What is the __Host- Cookie Prefix?
Learn what the __Host- cookie prefix requires, why Path=/ and no Domain matter, how it blocks weaker cookie injection, and when to use __Host- for session cookies.
Definition
The __Host- cookie prefix is a reserved cookie-name prefix that browsers accept only when the cookie is set with the Secure attribute, Path=/, and without a Domain attribute—binding the cookie tightly to the exact host that set it.
Why __Host- matters
Many cookie incidents come from scope that is wider than developers intended: Domain=.example.com shared across every subdomain, or duplicate cookies on different paths that applications parse incorrectly. The __Host- cookie prefix makes the browser refuse those weaker shapes for cookies that use the prefix.
For primary session identifiers, __Host- is often the strongest declarative cookie hardening available in mainstream browsers.
Rules the browser enforces
A cookie named with __Host- is accepted only when all of the following hold.
Secure must be set
The cookie is HTTPS-oriented and will not be accepted without Secure.
Path must be /
No alternate path-scoped duplicates under the same prefixed name.
Domain must be omitted
The cookie stays host-only to the exact host that set it.
Name starts with __Host-
The prefix itself is what triggers these acceptance checks.
How adoption works
Rename the session cookie
Choose a name such as __Host-session and update server readers/writers.
Emit a compliant Set-Cookie
Include Secure; Path=/; omit Domain; add HttpOnly and SameSite as appropriate.
Confirm browser acceptance
Verify the cookie appears in storage for the exact host after login.
Remove legacy cookie names
Invalidate old session cookies to prevent dual-cookie confusion.
__Host- vs __Secure-
| Topic | __Host- | __Secure- |
|---|---|---|
| Secure required | Yes | Yes |
| Domain allowed | No (must omit) | Yes |
| Path requirement | Must be / | No special Path mandate |
| Best fit | Primary host-only session | HTTPS cookie needing Domain/Path flexibility |
Checklist
- Use __Host- for the main authentication cookie when host-only scope is acceptable.
- Always pair with HttpOnly and an intentional SameSite value.
- Standardize on one canonical host (apex or www) for login cookies.
- Audit reverse proxies that inject Domain= automatically.
- Test login across environments that previously relied on shared subdomain cookies.
- Document any cookie that cannot use __Host- and justify __Secure- or unprefixed names.
- Watch for cookie tossing and duplicate-name issues during migration.
- Treat rejected Set-Cookie as a configuration bug, not a flaky client.
Limits
__Host- does not encrypt values, stop XSS from using an authenticated session, or replace CSRF defenses. It also cannot span www and bare apex. If your architecture requires cross-subdomain SSO via a shared cookie Domain, __Host- is the wrong tool for that particular cookie—harden differently and minimize the shared secret.
The practical takeaway
The __Host- cookie prefix forces Secure, Path=/, and host-only scope. Browsers reject non-compliant Set-Cookie attempts under that name.
Prefer __Host- for high-value session cookies whenever your hostname model allows it, and keep HttpOnly, SameSite, and server-side session controls alongside it.
Related security terms
Cookie Prefix
Overview of reserved cookie name prefixes and why browsers enforce them.
__Secure- Cookie Prefix
Less strict prefix that requires Secure but allows Domain/Path flexibility.
Secure Cookie
Secure attribute required by __Host- cookies.
Cookie Tossing
Attack pattern where __Host- constraints help reduce cookie confusion.
Frequently asked questions
What is the __Host- cookie prefix?
It is a special start of a cookie name. Browsers only store such a cookie if it is Secure, has Path=/, and omits Domain—making it host-only.
Why forbid the Domain attribute?
Omitting Domain keeps the cookie host-only. That prevents sibling subdomains from receiving or easily overwriting the same cookie under a shared Domain.
Why require Path=/?
Path=/ avoids multiple same-named cookies on different paths that can create ambiguous Cookie headers and application confusion.
When should I use __Host- instead of __Secure-?
Use __Host- for the primary session cookie when you can live with host-only scope and Path=/. Use __Secure- when you still need Domain or a narrower Path.
What happens if Domain is set on a __Host- cookie?
The browser rejects the Set-Cookie. The cookie will not be stored.
Does __Host- require HttpOnly?
The prefix rules do not require HttpOnly, but authentication cookies should still set HttpOnly separately.
Can www and apex both share a __Host- session?
No. A __Host- cookie set on www.example.com is not sent to example.com. Pick one host or use a different design if you need sharing.
References
Explore authoritative guidance and frameworks related to __host- cookie prefix.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.