Home / Knowledge hub / Cookie prefix
Knowledge hub
Cookie prefix
A name prefix such as __Host- that makes browsers enforce stricter cookie rules.
What it means
A cookie prefix is a fixed start to a cookie's name that tells the browser to apply extra rules. __Secure- means the cookie must have the Secure attribute and be set from a secure origin. __Host- goes further: Secure, no Domain attribute, and Path set to /.
A cookie that breaks the rules is simply rejected. The prefix turns a convention into something the browser enforces, so a mistake or an attacker cannot quietly weaken it.
Why it matters
The risk is a cookie being overwritten by a sibling subdomain or over plain HTTP. An attacker who controls an old subdomain, or sits on the network, can plant a cookie that your main site then trusts. That is the idea behind cookie tossing.
A __Host- cookie cannot be set from a subdomain at all, and it must be bound to your exact host. For session cookies, that closes a whole family of fixation tricks at almost no cost.
How it shows up
You meet it in session cookie names: __Host-session rather than session. It is set by the server in a Set-Cookie header and needs HTTPS. Browser support is broad across current browsers.
The mistakes repeat. Using __Host- but adding a Domain attribute, which makes the browser reject it and the app mysteriously logs everyone out. Using the prefix on a site still served over HTTP. Or using none at all on session and CSRF cookies. Pair with SameSite and HttpOnly.
Questions people ask
Cookie prefix, answered
What is the difference between __Secure- and __Host-?
__Secure- needs only the Secure attribute and a secure origin. __Host- also forbids a Domain attribute and requires Path=/.
So a __Host- cookie belongs to one exact host and cannot be set by a subdomain.
Do prefixes work in every browser?
Support is wide across current major browsers, and older ones simply treat the name as ordinary text, so the cookie still works without the extra protection.
They add safety without breaking anyone.
Does a prefix replace the Secure and HttpOnly flags?
No. The Secure flag is required by both prefixes. HttpOnly and SameSite are separate and you should still set them.
The prefix adds rules about where the cookie may be set, not who can read it.
Why does my __Host- cookie not get set?
Check that you are on HTTPS, that Secure is present, that there is no Domain attribute, and that Path is exactly /.
Failing any one makes the browser drop it without an error in the page.
Is it worth changing existing cookie names?
For session and CSRF cookies, usually yes. Changing the name signs existing users out once, so plan the release.
The rename can be done by accepting both names for a short period.
Sources
Where this comes from
Related
Terms that sit next to this one
Cookie tossing
A sibling subdomain planting cookies that your main site then trusts.
Secure cookie flag
A setting that makes the browser send a cookie only over HTTPS.
HttpOnly cookie
A cookie that page scripts cannot read, so XSS cannot simply steal it.
SameSite cookie
A cookie setting that limits when a browser sends it on requests from other sites.
Cookie scope
The domain and path settings that decide which sites and pages receive a cookie.
Can a subdomain set your cookie?
Weak cookie scope, planted cookies and session cookies that a sibling host can overwrite are within what we test, and each finding comes with the exact request. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.