A cookie prefix is a reserved name prefix that the browser treats specially when a Set-Cookie header is received: it stores the cookie only if extra constraints are met, otherwise it drops the whole header. Prefixes defend against cookie tossing and related integrity attacks by locking cookies to a host. The two prefixes are [[#__host-|__Host-]] and [[#__secure-|__Secure-]].
__Host-
__Host- prefix
A cookie whose name begins with __Host- is accepted by the browser only if all four conditions hold at the moment the Set-Cookie is received: it is marked Secure, it arrives from a secure (HTTPS) origin, it has no Domain attribute, and its Path is exactly /. If any condition fails the cookie is not stored at all.
Why Each Condition Matters: Each condition closes one lever a tossing attacker would otherwise use, so the result is a cookie that can only have come from the genuine host.
Secure
The cookie is sent only over HTTPS and cannot be set or overwritten by an HTTP request. This blocks a network attacker from downgrading the connection and injecting a __Host- cookie in the clear.
From a secure origin
The Set-Cookie must arrive over an HTTPS response from the host itself. Combined with Secure, this rules out any planting attempt that does not already hold a secure channel to the host — so a same-site attacker who can only serve plain HTTP from a subdomain cannot mint the cookie.
No Domain attribute
The load-bearing condition. A cookie without Domain is automatically scoped to the exact host that set it, so a subdomain-planted __Host-sid would be sent only to that subdomain and never to the apex. This removes exactly the lever that tossing uses — a Domain=bank.com cookie planted from evil.bank.com widening to the whole of bank.com. With no Domain allowed, the subdomain cookie has no way to enter the apex’s jar.
Path=/
Forces every __Host- cookie to use the most general path. This blocks the more-specific-path ordering trick (a planted path=/account/ cookie winning over a genuine path=/ one in the Cookie request header) by making all __Host- cookies share one path, so the browser cannot order a planted one above the genuine one.
__Secure-
__Secure- prefix
A cookie whose name begins with __Secure- is accepted only if marked Secure and arriving from a secure origin — i.e. it pins the cookie to HTTPS but, unlike __Host-, does not forbid Domain. So a same-site attacker can still widen a __Secure- cookie to the apex and toss it; __Secure- is therefore weaker than __Host- and is not a defence against cookie tossing. Use it only when Domain widening is genuinely needed and the cookie is not security-critical.