Cookie Prefixes

Cookie name prefixes let browsers enforce security-related rules when setting cookies. The most important prefixes for frontend security are `__Secure-` and `__Host-`, with `__Host-` imposing the stricter constraints.

Cookie prefixes are special strings at the beginning of a cookie name that trigger browser-enforced requirements. They are useful because the browser can reject a cookie that violates the prefix's rules, rather than relying only on application conventions.

A cookie named with the `__Secure-` prefix must be set with the `Secure` attribute. This means the cookie is intended to be sent only over HTTPS connections. The prefix therefore helps prevent an insecure response from successfully creating a cookie that the application intended to protect with `Secure`.

The `__Host-` prefix is stricter. A `__Host-` cookie must use `Secure`, must have `Path=/`, and must not specify a `Domain` attribute. Consequently, the cookie is host-only and cannot be deliberately scoped to a parent domain through the cookie's `Domain` attribute.

These constraints are enforced when the browser processes the `Set-Cookie` response. A useful security benefit is protection against some cookie-setting mistakes and attempts to create a conflicting cookie from a broader domain. Prefixes do not replace other protections such as `HttpOnly`, `SameSite`, CSRF defenses, or careful session management.

For a session cookie that should belong only to the exact host and be available throughout that host, `__Host-` is often a useful naming convention when its requirements fit the deployment architecture.

Key points

• `__Secure-` requires the `Secure` attribute.
• `__Host-` requires `Secure` and `Path=/`, and forbids `Domain`.
• Cookie-prefix requirements are enforced by the browser when cookies are set.
• `__Host-` produces a host-only cookie because it cannot specify `Domain`.
• Prefixes complement, rather than replace, `HttpOnly`, `SameSite`, and other defenses.

Interview questions

What is the purpose of cookie prefixes?

Cookie prefixes allow the browser to enforce certain security constraints based on the cookie name. For example, `__Secure-` requires the `Secure` attribute. This reduces reliance on application developers remembering every required attribute correctly. Prefixes are therefore a defense-in-depth mechanism for cookie security.

What requirements does a `__Host-` cookie have?

A `__Host-` cookie must be set with `Secure` and `Path=/`. It must not contain a `Domain` attribute. These rules make the cookie host-only and prevent it from being deliberately scoped to a parent domain.

What is the difference between `__Secure-` and `__Host-`?

Both prefixes require the cookie to use `Secure`. `__Host-` adds two important restrictions: the cookie must use `Path=/`, and it cannot specify `Domain`. Therefore, `__Host-` provides tighter control over where the cookie is scoped.

Does using `__Host-` make a session cookie completely secure?

No. `__Host-` constrains how the cookie can be created and scoped, but it does not address every cookie attack or session-management problem. For example, an application still needs to choose appropriate `HttpOnly` and `SameSite` settings and defend against application-level vulnerabilities such as XSS and CSRF where relevant. It also needs proper session expiration, rotation, and invalidation policies.

Why can `__Host-` cookies help with cookie injection or shadowing scenarios?

The prefix prevents the cookie from specifying a `Domain` and requires `Path=/`, which limits the ways another context can create a cookie with the same host-scoped semantics. This reduces ambiguity caused by broader domain scoping. It does not eliminate every possible cookie-confusion issue, so applications still need careful session-cookie design and validation.