In one paragraph
A session cookie without the __Host- prefix lacks that name-based browser guarantee of host-only scope. Supporting browsers require a prefixed cookie to use Secure, Path=/, and no Domain attribute. Consider the prefix for sessions that belong to one hostname, but first review cross-subdomain sign-in and infrastructure rules. It is optional hardening, not a substitute for correct session management.
Why it matters
Ordinary cookie scoping can allow one subdomain to set a parent-domain cookie that another subdomain receives. If a sibling host is untrusted or compromised, this can contribute to cookie tossing, shadowing, or session-fixation problems, depending on the application's parsing and session design.
The __Host- prefix makes supporting browsers enforce a narrower contract. The cookie is set from a secure origin with Secure, uses Path=/, and omits Domain. A sibling cannot create a parent-domain version under that prefixed name and make it a cookie for the target host.
The prefix does not itself require HttpOnly or select SameSite. It does not encrypt the token value, stop all XSS consequences, or implement rotation and revocation. A JavaScript-accessible cookie can still use this prefix when its other rules are satisfied; do not describe __Host- as a server-only or HttpOnly guarantee.
How WebAuditOS evaluates this finding
The supplied rule classifies cookie names containing session, sid, token, or auth as session-like. Every matching cookie must start with the expected prefix to pass; a missing prefix warns informationally. No response cookie or no matching name is not graded.
The heuristic can include CSRF tokens and miss an unusually named real session. It checks names rather than validating all prefix attributes, and it does not see JavaScript-created cookies. A passing observed name is not proof that the browser accepted the cookie or that every authentication route uses it.
How to fix it
- Identify what the flagged cookie actually does. Confirm whether it is a session, a separate token, or an unrelated identifier. Review the application configuration and all hosts expected to receive it.
- Decide whether host-only scope is compatible. A session deliberately shared using Domain=example.com cannot retain that parent-domain sharing while satisfying __Host-. Consider per-host sessions and a central authentication flow if the architecture justifies it, rather than casually renaming a shared cookie.
- Configure the issuing component with an exact prefixed name and required attributes. A conventional server-managed session example is:
Set-Cookie: __Host-session=REPLACE_WITH_TOKEN; Secure; HttpOnly; SameSite=Lax; Path=/There is no Domain attribute, including no explicit Domain equal to the current host. Replace the token and choose SameSite according to the real authentication flow.
- Plan the transition. Renaming can log users out if the server stops recognising the old name. If using a controlled migration period, prevent ambiguous parsing or acceptance of attacker-planted legacy values. Invalidate or expire old sessions and scoped cookies deliberately.
- Update dependent infrastructure. Review cache-bypass rules, WAF conditions, load-balancer affinity, test fixtures, and any code reading a separate token cookie. A CDN that no longer recognises the session can create a more serious problem than an informational prefix warning.
- Verify HTTPS handling through trusted proxies and supported development environments. A browser can reject a prefixed cookie with invalid attributes even when an HTTP response appears successful. Inspect storage and browser diagnostics, not only the header string.
- Test login, refresh, renewal, logout, and separate subdomain journeys with non-production accounts. Confirm authenticated pages are not unintentionally cached for other users.
- Rescan the relevant issuing routes and record any justified shared-cookie exception. A documented tradeoff is preferable to breaking the sign-in architecture solely to clear the warning.
What the fix can break
Cross-subdomain sessions and single sign-on flows can fail because host-only cookies are not sent to sibling hosts. The fix may require an authentication architecture change, not another attribute.
Cookie names are case-sensitive and prefix rules are specific. Update every issuer consistently and check renewal paths, not just initial login.
Do not migrate a session into localStorage merely to avoid the cookie warning. That changes the token's exposure and discards the protections provided by server-issued HttpOnly cookies.
Questions
Does __Host- automatically imply HttpOnly?
No. Add HttpOnly separately for cookies that must not be read by JavaScript. The prefix addresses scope and secure setting requirements.
Can I keep Domain for a shared login?
Not on a valid __Host- cookie. Omit Domain or use a different deliberate design for the shared token.
Why does the renamed cookie not appear in storage?
Inspect Secure, Path=/, Domain absence, the secure issuing context, and exact name. The browser may reject an invalid prefixed cookie.