Cookie Prefixes Explained: When to Use __Host- and __Secure- for Session Cookies

Use browser-enforced cookie prefixes to reduce session-cookie scope and configuration mistakes, while keeping HttpOnly, SameSite, CSRF, and session lifecycle controls intact.

Back to Blog

Cookie Prefixes Explained: When to Use __Host- and __Secure- for Session Cookies

Secure, HttpOnly, and SameSite are the cookie attributes most developers recognize. Cookie name prefixes add another useful layer. Modern browsers understand prefixes such as __Secure- and __Host- and reject cookies that use those names without meeting specific security requirements.

These prefixes are valuable because they make part of the cookie's security contract enforceable by the browser. They do not replace session security, CSRF defenses, HTTPS, or correct Domain and Path design, but they can prevent unsafe cookie configurations and some forms of cookie shadowing or fixation.

What __Secure- requires

A cookie whose name starts with __Secure- must be set from a secure HTTPS origin and include the Secure attribute. A browser that supports the prefix will reject a non-compliant attempt.

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

The prefix does not require HttpOnly, SameSite, or a particular Path or Domain value. Those still need to be chosen according to the application.

What __Host- requires

__Host- is stricter. The cookie must be set from HTTPS, must include Secure, must use Path=/, and must not include a Domain attribute.

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

Because there is no Domain attribute, the cookie is host-only. A sibling subdomain cannot deliberately set the same __Host- cookie for the parent domain.

Why the Domain attribute matters

A cookie set with Domain=example.com can be sent to multiple subdomains. That may be necessary for some applications, but it also expands the trust boundary. A compromised or less-trusted subdomain can become relevant to cookie integrity.

If a session is only needed on app.example.com, a host-only cookie is usually easier to reason about than a domain-wide cookie.

Why __Host- is a strong choice for many session cookies

For an application that does not need to share its session cookie across subdomains, __Host- expresses a useful contract: HTTPS only, host-only, and valid across the whole host path. That removes several opportunities for accidental weakening.

It also makes configuration mistakes visible during testing because the browser refuses a malformed prefix cookie instead of silently accepting weaker scope.

When __Secure- may be more practical

Some applications intentionally share a cookie across subdomains. In that design, __Host- cannot be used because it forbids the Domain attribute. __Secure- can still require HTTPS while allowing the wider domain scope.

Before sharing a session cookie, ask whether the architecture truly requires it. Separate host-specific sessions can reduce the number of systems that can influence authentication state.

Prefixes do not automatically add HttpOnly

A session cookie normally benefits from HttpOnly so JavaScript cannot read it through document.cookie. The __Secure- and __Host- prefixes do not imply HttpOnly.

Set the attribute explicitly for cookies that do not need client-side JavaScript access.

SameSite still matters

Cookie prefixes do not determine cross-site sending behavior. Choose SameSite=Lax, Strict, or None based on the legitimate flow. If SameSite=None is required, browsers require the Secure attribute.

OAuth, federated login, embedded applications, and cross-site payment flows may need careful testing because overly strict SameSite settings can break legitimate navigation.

Path is not an authorization boundary

A cookie Path controls when the browser sends the cookie. It should not be treated as a robust security boundary between applications on the same host. The __Host- prefix specifically requires Path=/, avoiding a class of same-name cookies scoped to narrower paths.

Applications can behave unpredictably when multiple cookies share the same name with different Domain or Path attributes. Server frameworks may choose one value based on ordering that developers do not expect.

Using a host-only session cookie with a unique prefixed name reduces ambiguity. During migration, remove obsolete cookie names deliberately so old clients do not keep sending conflicting values.

Subdomains change the threat model

Marketing platforms, customer support systems, user-generated content, legacy apps, and staging environments often live on subdomains. If those hosts can set domain-wide cookies, their compromise can affect the security of the main application.

Review DNS and subdomain ownership before deciding that every sibling host belongs inside the authentication trust boundary.

Session rotation is still required

A perfectly configured cookie can carry a poorly managed session ID. Rotate session identifiers after login and privilege changes. Expire sessions appropriately. Invalidate server-side state at logout when the session model supports it.

Cookie attributes reduce browser-side exposure. They do not fix weak session lifecycle management.

CSRF is still a separate control

SameSite can reduce cross-site request forgery risk, but applications should still use appropriate CSRF protections for state-changing requests, especially when flows require permissive cookie behavior.

A cookie prefix tells the browser how a cookie may be set. It does not prove that a request using the cookie was intended by the user.

Changing session to __Host-session creates a new cookie name. Plan the transition. You may need to accept both names temporarily, issue the new cookie after authentication, expire the old cookie, and confirm every application node uses the same policy.

Test logout, remember-me behavior, token refresh, password reset, and multi-tab sessions. Cookie changes can reveal hidden assumptions in authentication middleware.

Browser enforcement is defense in depth

Supporting browsers enforce the prefix rules, but your server should still set the complete expected attributes and validate sessions normally. Do not weaken server logic because the browser is expected to reject a malformed cookie.

Automated clients, unusual user agents, and backend integrations may not behave like mainstream browsers.

Vulnify's scanner includes cookie security checks within its website assessment scope, and the Security Headers Analyzer can help review the surrounding browser security posture. Cookie prefixes are one detail in a larger session-security design.

A public scan can observe attributes returned by the application. It cannot prove that server-side session rotation, revocation, CSRF, or authorization logic is correct.

  • Use HTTPS for all session-bearing pages.
  • Prefer __Host- for host-specific session cookies.
  • Use __Secure- when secure cross-subdomain scope is genuinely required.
  • Add HttpOnly to server-only session cookies.
  • Choose SameSite deliberately.
  • Avoid Domain scope unless the application needs it.
  • Remove obsolete duplicate cookie names during migration.
  • Rotate session IDs after authentication and privilege changes.
  • Keep CSRF protections appropriate to the application flow.

MDN also documents __Http- and __Host-Http- prefixes, which add an HttpOnly requirement to the Secure requirements and, for the host variant, the same host-only restrictions as __Host-. Browser support can evolve, so check your supported user agents before relying on newer prefixes.

The long-established __Host- and __Secure- prefixes remain useful because their meaning is simple and widely understood.

A large organization may delegate subdomains to marketing tools, support platforms, customer content, regional systems, or temporary projects. Domain-wide cookies pull those systems into the session trust boundary. Host-only cookies reduce that coupling.

Before setting Domain=example.com, inventory who controls sibling hosts. A convenience decision in authentication can become an organization-wide dependency.

During browser testing, deliberately try a non-compliant cookie in a development environment. For example, attempt to set a __Host- cookie with a Domain attribute and confirm the browser refuses it. This validates that the prefix is actually being interpreted rather than merely used as a naming convention.

Then inspect the final production Set-Cookie headers, because reverse proxies and application middleware can alter attributes between code and the browser.

Multiple applications on one host deserve careful cookie naming

If several applications share one hostname, Path cannot be treated as strong isolation. Use distinct cookie names and consider separating high-trust applications onto different hosts. A host-wide session cookie should be understood by every application that receives it.

Authentication boundaries are easier to reason about when DNS and cookie scope align.

A cookie-name migration can cause confusing login loops if one service still reads the old name or a proxy strips an attribute. Monitor authentication errors, repeated login redirects, and unexpected session creation during deployment.

Test across browsers in your supported matrix and across every hostname involved in sign-in. If the application uses a separate identity host, make sure the chosen prefix and Domain model matches that architecture rather than forcing a host-only cookie where cross-host sharing is required.

Application code may set the right cookie while an edge function, reverse proxy, or identity gateway rewrites it. Inspect the final Set-Cookie header received by the browser, especially after CDN or authentication changes. Security decisions should be based on the deployed response rather than framework configuration alone.

Match the prefix to the authentication topology

If login happens on one host and the application consumes the session on another, forcing a host-only cookie may be the wrong design. Map the real trust boundary first. The goal is the narrowest cookie scope that still supports the intended authentication flow.

For each session-related cookie, record its purpose, owning service, Domain, Path, SameSite choice, lifetime, and whether JavaScript access is required. That small inventory makes later migrations and incident response much easier.

Cookie prefixes are small controls with a useful property: they let the browser reject certain insecure configurations. For a host-specific session, __Host- is often a clean default. The important part is understanding what the prefix guarantees and continuing to secure everything it does not.