Cookie Prefixes Bind Browser-Enforced Constraints to Cookie Names

HTTP cookies carry security attributes such as Secure, HttpOnly, Domain, and Path. Cookie prefixes add another layer: a reserved pattern in the cookie name tells a supporting browser that specific attributes must accompany the cookie. If the Set-Cookie header violates that contract, the browser rejects the cookie instead of storing it under weaker settings.

This mechanism is useful because configuration intent becomes visible in the name itself. A session cookie named with a host-bound prefix cannot silently drift into a domain-scoped cookie without failing the browser’s prefix checks.

__Secure- requires secure transport

A cookie whose name starts with __Secure- must be set from a secure HTTPS context and must carry the Secure attribute.

Set-Cookie: __Secure-session=VALUE; Secure; HttpOnly; SameSite=Lax

The prefix does not require HttpOnly, SameSite, a particular Path, or the absence of Domain. Those controls remain separate choices. The prefix establishes a narrower invariant: the cookie must satisfy the secure-setting requirement.

A header that omits Secure does not meet that contract:

Set-Cookie: __Secure-session=VALUE; HttpOnly

On a user agent that enforces cookie prefixes, the cookie is rejected rather than accepted as an ordinary insecure cookie.

__Host- also removes domain scope

The __Host- prefix has stricter conditions. The cookie must be set from a secure HTTPS context, include Secure, omit the Domain attribute, and use Path=/.

Set-Cookie: __Host-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Omitting Domain makes the cookie host-only. A response from app.example.com cannot use a __Host- cookie while also declaring Domain=example.com to share it with sibling hosts.

The required root path also prevents the same prefixed name from being intentionally scoped to a narrower URL path. The result is a cookie tied to the host that set it and available across that host’s paths.

These headers violate the prefix contract:

Set-Cookie: __Host-session=VALUE; Secure; Path=/; Domain=example.com
Set-Cookie: __Host-session=VALUE; Secure; Path=/account
Set-Cookie: __Host-session=VALUE; Path=/

The first adds domain scope, the second narrows the path, and the third omits Secure.

The prefix is not shorthand that causes a browser to add missing attributes. __Host- does not automatically insert Secure or Path=/; the server must send the required attributes. __Secure- likewise does not add Secure to a malformed header.

This distinction makes prefix checks useful as an invariant. Application code, framework defaults, reverse proxies, and authentication middleware may all participate in cookie construction. If a later change removes an attribute required by the prefix, a supporting browser refuses the resulting cookie rather than quietly accepting the weaker form.

That failure can break a session flow, so deployment still needs testing. A rejected cookie can appear operationally as repeated login, missing state, or a request that never receives the expected session identifier.

HttpOnly remains an independent boundary

HttpOnly prevents script APIs such as Document.cookie from reading or modifying the cookie. Neither __Secure- nor __Host- implies HttpOnly.

For a server-managed session cookie, a common combination is:

Set-Cookie: __Host-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Each part has a distinct role. __Host- constrains host, path, and secure-setting properties. HttpOnly limits script access. SameSite controls cross-site sending behavior according to its selected mode. The controls compose, but they are not interchangeable.

A cookie can therefore satisfy the __Host- contract and still be readable by JavaScript if HttpOnly is absent. Prefix validation should not be treated as a complete session-cookie policy.

Newer HTTP-bound prefixes add another contract

Current browser documentation also describes __Http- and __Host-Http-. These forms require Secure and HttpOnly, expressing that the cookie must be created through an HTTP Set-Cookie header rather than client-side cookie APIs. __Host-Http- additionally carries the host-only and root-path restrictions associated with __Host-.

Set-Cookie: __Host-Http-session=VALUE; Secure; HttpOnly; Path=/; SameSite=Lax

Support for individual prefix forms can vary across user agents. A deployment that depends on a newer prefix needs compatibility checks for its actual client population. Prefix syntax should reinforce server policy, not become the only control protecting a sensitive cookie.

Subdomains make host binding operationally significant

Consider an application split across these hosts:

app.example.com
static.example.com
support.example.com

A domain cookie for example.com can be sent to multiple subdomains. That may be intentional for some state, but it expands the set of hosts involved in the cookie boundary.

A __Host- cookie set by app.example.com cannot declare Domain=example.com. This prevents that prefixed cookie from being broadened to sibling hosts through its attributes. For authentication state that belongs only to the application host, the restriction makes the intended scope explicit.

It does not make every subdomain safe, nor does it isolate all browser state by itself. Other cookies, storage APIs, redirects, script execution, and application trust relationships still need separate review.

Prefixes do not solve XSS or CSRF

Cookie prefixes constrain cookie creation and scope. They do not sanitize HTML, block injected scripts, validate request intent, or make a session identifier harmless after theft.

HttpOnly can reduce direct script access to a session cookie, but an XSS flaw may still issue authenticated requests from the victim’s page. SameSite can restrict some cross-site cookie sending, but its semantics are separate from prefix enforcement. CSRF defenses may still require request tokens, origin checks, or other application-specific controls.

The useful property of a prefix is narrower: it lets the browser reject a cookie when the cookie’s declared name and security attributes disagree.

Treat rejection as a configuration signal

Cookie configuration often changes at several layers. A framework upgrade can alter defaults, a proxy can terminate TLS, and different routes can emit different Set-Cookie headers. Prefixes turn some classes of accidental weakening into visible failures.

Tests can assert the complete header, including exact capitalization of the prefix and required attributes. Browser integration tests can also confirm that invalid variants are not stored.

For a host-bound session cookie, a compact review checklist is concrete:

name starts with __Host-
response uses HTTPS
Secure is present
Domain is absent
Path=/
HttpOnly is present when script access is unnecessary
SameSite matches the application's request model

The last two lines are policy choices beyond the base __Host- contract, but they matter for many session designs.

Cookie prefixes work best as enforceable naming contracts. They do not replace careful session design, yet they make selected cookie invariants harder to weaken accidentally. When the name says __Host-, a supporting browser expects the attributes to preserve that host-bound boundary.

References

Cybersecurity HTTP Cookies Web Security Session Security