Cybersecurity glossary
What is a Cookie Prefix?
Learn what cookie prefixes are, how __Host- and __Secure- force stronger Set-Cookie rules, which browser checks apply, and when to adopt prefixes for session cookies.
Definition
A cookie prefix is a special name prefix—most notably __Host- and __Secure-—that browsers enforce with extra security requirements when a cookie is set, rejecting the cookie if mandatory attributes such as Secure or a strict Path/Domain combination are missing.
Why cookie prefixes matter
Security attributes on cookies only help when every Set-Cookie is written correctly. Misconfigurations happen: a reverse proxy strips Secure, a staging template omits Path, or an attacker injects a cookie under a trusted name from a weaker context.
Cookie prefixes move key requirements from documentation into browser enforcement. If the name starts with __Host- or __Secure-, the browser validates mandatory rules before accepting the cookie. That turns silent misconfiguration into a hard failure—usually preferable to a silently weak session cookie.
How cookie prefixes work
The prefix is part of the cookie name. Browsers recognize reserved prefixes and apply extra acceptance checks during cookie storage.
Choose a prefixed cookie name
Use __Host- or __Secure- at the start of the name for cookies that must meet hardened rules.
Emit a compliant Set-Cookie
Include Secure and any other attributes required by the chosen prefix.
Browser validates prefix rules
Non-compliant cookies are rejected instead of stored with weaker settings.
Application relies on the strong cookie
Only a correctly hardened cookie under that name can exist in the jar for matching scope.
Prefixes compared
| Prefix | Browser requires | Best for |
|---|---|---|
| __Secure- | Secure attribute; set over a secure channel | HTTPS-only cookies that may still use Domain/Path flexibility |
| __Host- | Secure, Path=/, and no Domain attribute | Highest-assurance host-only cookies such as primary session IDs |
What prefixes protect against
Accidental weak flags
A forgotten Secure attribute cannot quietly create a __Secure- or __Host- cookie.
Broader domain confusion
__Host- forbids Domain, reducing subdomain cookie-sharing surprises.
Some cookie injection paths
Attackers who can set cookies only in weaker contexts may fail to overwrite a prefixed name.
Operational drift
Proxies and templates that strip attributes cause visible breakage instead of silent insecurity.
Adoption checklist
- Identify authentication and CSRF cookies that deserve browser-enforced hardening.
- Prefer __Host- for the primary session cookie when Path=/ and host-only scope are acceptable.
- Use __Secure- when you still need a Domain or non-root Path but must require Secure.
- Update every code path that sets or reads the cookie name.
- Verify behavior behind CDNs and API gateways that rewrite Set-Cookie.
- Test login, logout, and session refresh after renaming cookies.
- Document why a cookie is not prefixed if it cannot meet the rules.
- Monitor support metrics if you still serve very old browser clients.
Limits to keep in mind
Prefixes do not encrypt cookie values, stop XSS from using a stolen session through requests, or replace SameSite/CSRF design. They also cannot help if your application never sets the cookie because a proxy always strips required attributes.
Treat prefixes as a strong complement to Secure, HttpOnly, SameSite, short lifetimes, and server-side session binding—not as a complete session-security program.
The practical takeaway
A cookie prefix reserves part of the cookie name so browsers enforce stricter Set-Cookie rules. __Secure- and especially __Host- turn important hardening requirements into mechanical checks.
Use prefixes on high-value cookies so misconfiguration fails closed, then keep the rest of your session defenses in place.
Related security terms
__Host- Cookie Prefix
The stricter prefix that requires Secure, Path=/, and no Domain attribute.
__Secure- Cookie Prefix
The prefix that requires the Secure attribute on HTTPS-set cookies.
Secure Cookie
Base Secure attribute that prefixed cookies also depend on.
Cookie
General HTTP cookie model that prefixes harden further.
Frequently asked questions
What is a cookie prefix in simple terms?
It is a reserved start of a cookie name that tells the browser to enforce extra rules. If the Set-Cookie line does not meet those rules, the browser ignores the cookie.
Which cookie prefixes matter most?
The widely supported security prefixes are __Host- and __Secure-. They prevent weaker cookies from being accepted under those names.
Why use a cookie prefix instead of only setting Secure?
Prefixes make the browser reject misconfigured Set-Cookie attempts. That blocks some cookie injection and configuration mistakes that a human checklist can miss.
Can I rename an existing session cookie to add a prefix?
Yes, but you must update server code that reads the cookie name and ensure all Set-Cookie paths emit the required attributes. Plan a migration so old and new names do not confuse sessions.
Do all browsers support cookie prefixes?
Modern major browsers support __Host- and __Secure-. Always verify target browser baselines for your audience.
Are cookie prefixes the same as Cookie Prefixes in privacy sandboxes?
No. Here the term means the __Host- and __Secure- name-prefix security mechanism for Set-Cookie, not a separate advertising API.
What happens if attributes are wrong for a prefixed cookie?
The browser discards that Set-Cookie. The application may look as if it never set the cookie at all.
References
Explore authoritative guidance and frameworks related to cookie prefix.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.