< Set-Cookie: __Host-id=a3fWa; Secure; Path=/

TL;DR: A cookie whose name starts with __Host- is only accepted if it has Secure, Path=/ and no Domain, and was set over HTTPS. __Secure- only demands Secure over HTTPS. The browser enforces this, so a subdomain or a network attacker cannot overwrite your session cookie.

The rules

From RFC 6265bis section 4.1.3 (still an Internet-Draft; it was in the RFC Editor queue when this page was last reviewed):

Prefix	Secure attribute	Set from HTTPS	Domain attribute	Path attribute
__Secure-	Required	Required	Allowed	Any
__Host-	Required	Required	Forbidden	Must be /

Set-Cookie: __Secure-theme=dark; Secure; Domain=example.com; SameSite=Lax
Set-Cookie: __Host-sid=a3fWa9; Secure; Path=/; HttpOnly; SameSite=Lax

If a Set-Cookie header with a prefixed name violates its rules, the browser discards the cookie. There is no error in the page and no Set-Cookie echo in document.cookie; the symptom is “the cookie never appears”. Server-side, the draft says a name starting with the case-sensitive string __Secure- implies the cookie was set with Secure. User agents must match the prefix case-insensitively, which prevents a mis-capitalized __host- name from dodging the checks while a server that folds case still reads it.

What problem prefixes solve

Cookies are scoped by host, not origin, and a cookie from evil.example.com with Domain=example.com is sent to app.example.com. If it has the same name as your session cookie, the browser may send both, and many frameworks read the first one. This is cookie tossing, and it feeds session fixation and CSRF-token overwrite. An HTTP-only network attacker can do the same by injecting a cookie into a plain HTTP response for your domain.

• __Host- closes both holes. Without Domain the cookie is host-only, so a sibling subdomain cannot set one that collides, and Secure stops the HTTP injection. Path=/ stops a different path on the same host from planting one.
• __Secure- only closes the HTTP injection. It is for cookies that must span subdomains.

Prefixes are the right default for session and CSRF cookies. The Secure attribute alone leaves the subdomain case open.

Setting a __Host- cookie in common stacks

Express with express-session:

app.set('trust proxy', 1) // so req.secure is true behind a TLS-terminating proxy
app.use(session({
  name: '__Host-sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { secure: true, httpOnly: true, sameSite: 'lax', path: '/' } // no domain
}))

Laravel reads these from config/session.php, with environment overrides:

SESSION_COOKIE=__Host-laravel_session
SESSION_SECURE_COOKIE=true
SESSION_PATH=/
SESSION_DOMAIN=null

SESSION_DOMAIN=null is what keeps Domain out of the header. If another layer, such as a CDN rule or a legacy middleware, appends Domain=, the cookie vanishes. From JavaScript the same restrictions apply: document.cookie = "__Host-flag=1; Secure; Path=/" works on HTTPS pages and is rejected on http://.

Debug checklist

1. Run curl -si https://example.com/login | grep -i set-cookie and look for Domain= and Path= on the __Host- line.
2. Behind a proxy, confirm the app sees HTTPS (X-Forwarded-Proto); a framework that only adds Secure for HTTPS requests will omit it, and the browser will drop the cookie.
3. Make sure every environment, including localhost, serves the cookie over HTTPS. Chrome and Firefox treat http://localhost as secure; Safari has historically not.
4. Change the cookie name only with a migration plan: users with the old unprefixed cookie are logged out when you rename it.

Newer prefixes

MDN also documents __Http- (requires Secure and HttpOnly) and __Host-Http- (the __Host- rules plus HttpOnly). Its compatibility data lists them as supported from Chrome 140 and Firefox 143, and not in Safari. Use them as an addition where you can, not as a replacement for __Host-.

With Partitioned cookies

Partitioned cookies are recommended to use the __Host- prefix, so a third-party embed’s state is bound to its own host and partition.