The __Host- Cookie Prefix Constrains Cookie Scope

Cookie security depends on more than the value stored in a cookie. Scope determines which requests can carry it and which responses can attempt to replace it. For a sensitive session cookie, a broad domain rule can give sibling hosts influence that the application did not intend.

The __Host- cookie name prefix gives supporting browsers a compact set of scope requirements. A cookie whose name starts with __Host- is accepted only when it is set with Secure, has Path=/, and omits the Domain attribute. The result is a host-only cookie available across paths on that host and restricted to secure transport.

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

The prefix does not create a new authentication protocol. It makes several cookie invariants browser-enforced instead of relying only on application configuration.

Omitting Domain is a security property

A cookie without a Domain attribute is host-only. The browser returns it only to the host that set it, subject to the cookie’s other rules.

A domain cookie has broader reach. For example, a cookie set for example.com can be sent to eligible subdomains. That may be required for some designs, but it also expands the set of hosts participating in the cookie boundary.

__Host- rejects that expansion. This header is invalid for the prefix because it includes Domain:

Set-Cookie: __Host-session=opaque-value; Secure; Domain=example.com; Path=/

A service that needs one cookie shared across sibling hosts therefore cannot use __Host- for that cookie. The restriction is intentional.

Path must be the root

The prefix also requires Path=/.

Cookie paths control delivery, but they are not an authorization boundary between mutually distrusting applications on the same host. Requiring the root path avoids presenting a __Host- cookie as both host-bound and path-fragmented. The prefix has one clear scope model: one host, secure transport, all paths.

A narrower path such as the following does not satisfy the prefix contract:

Set-Cookie: __Host-session=opaque-value; Secure; Path=/admin

Applications can still use ordinary cookies with narrower paths when that behavior is useful. They simply do not receive the browser-enforced __Host- guarantees.

Secure is mandatory

A __Host- cookie must carry the Secure attribute. That limits transmission to secure contexts as defined by cookie processing rules.

Set-Cookie: __Host-session=opaque-value; Secure; HttpOnly; Path=/

Secure is necessary, but it does not provide all session protections. HttpOnly remains a separate attribute for preventing access through document.cookie. SameSite remains a separate policy for cross-site cookie delivery. Expiration and session invalidation remain application concerns.

The prefix composes with those controls rather than replacing them.

The prefix reduces configuration drift

Cookie settings are often assembled in framework middleware, reverse proxies, authentication libraries, and environment-specific configuration. A deployment mistake can silently widen a conventional cookie if the resulting header remains syntactically valid.

The __Host- prefix moves three requirements into browser processing. If a response tries to set the prefixed cookie with a Domain attribute, without Secure, or with a path other than /, a conforming browser does not store it as that cookie.

That failure mode is useful because an invalid configuration does not quietly degrade into a broader __Host- cookie. Deployment tests should still inspect actual Set-Cookie headers and browser behavior; the prefix is a constraint, not a substitute for verification.

Sibling hosts remain separate principals

Consider app.example.com and files.example.com. If the application session is a domain cookie for example.com, both hosts sit inside a wider cookie scope. A host-only __Host-session created by app.example.com does not extend that session cookie to files.example.com.

This separation is valuable when subdomains have different operators, deployment stacks, or content trust. It also reduces dependence on every sibling host preserving the session cookie’s integrity.

The prefix does not isolate two applications that share the same host. If unrelated applications live under different paths on one hostname, cookie path rules do not turn those paths into strong security principals. Host separation is the cleaner boundary when applications require distinct cookie authority.

__Secure- has a different contract

The related __Secure- prefix requires Secure, but it does not impose the host-only and root-path requirements of __Host-.

That makes __Secure- suitable for cases that need a prefixed secure cookie but also need a Domain attribute or another path. It is a weaker scope constraint, not an alias for __Host-.

Choosing between them should follow the cookie’s actual delivery requirements. A host-local session is a strong candidate for __Host-; a cookie intentionally shared across subdomains cannot satisfy that contract.

Prefixes do not repair application authorization

A tightly scoped cookie can still represent an overprivileged session. A request carrying __Host-session still needs normal authentication, authorization, CSRF defenses where applicable, safe session rotation, and server-side invalidation.

The prefix also does not protect a session value from every compromise of the host that owns it. Script injection, server compromise, insecure session lifecycle logic, and credential theft require controls at their respective layers.

Its contribution is specific: the cookie name declares a scope contract, and supporting browsers enforce that contract when the cookie is set. For sensitive host-local sessions, that turns a small naming convention into a useful guard against accidental domain broadening and inconsistent cookie attributes.