Session cookies shared with every subdomain

A cookie set with no Domain attribute is host-only: it is sent back only to the exact host that set it.

A cookie set with a Domain attribute is sent to that domain and every subdomain, and the browser ignores any attempt to narrow it back afterwards.

There is no way to exclude a subdomain once the wider scope is set, so the decision is all or nothing per cookie.

The Path attribute narrows within a host and is not a security boundary, since any page on the host can read cookies at any path through script unless they are HttpOnly.

Which means the Domain attribute is the one that decides where a credential travels.

A site spanning the apex and the www hostname, where a session has to survive a visitor moving between them.

A single sign-on arrangement across several subdomains, which is a legitimate reason and the main one.

A framework default that sets the attribute without being asked.

A copied configuration from a project where the wider scope was needed.

In the first two cases it is a decision; in the last two it is an inheritance nobody reviewed.

The cookie is transmitted on every request to every subdomain, including ones serving static assets where it is pure overhead.

A subdomain running third-party software — a help desk, a status page, a documentation platform — receives it too, and that software can read it unless it is HttpOnly.

A subdomain given to a vendor, or pointed at a platform by CNAME, is outside your control entirely and still receives the cookie.

A subdomain compromised at any point can read every cookie scoped to the parent, which turns one weak host into a session problem for the main application.

And the transfer cost is real: a large cookie on a wide scope is re-sent with every asset request.

Set session and authentication cookies host-only unless a subdomain genuinely consumes them.

Where single sign-on across subdomains is required, use a dedicated cookie for that purpose and keep the session cookie host-only.

Serve static assets from a host that shares no cookie scope with the application, which removes the overhead entirely.

Combine the narrow scope with HttpOnly, Secure and a strict SameSite, which is the full set for a credential.

Consider the host-prefixed cookie naming convention, which browsers enforce as host-only and secure — the strongest available guarantee.

A cookie name beginning with the host prefix is only accepted by browsers when it is set with no Domain attribute, a path of the root, and the Secure attribute.

A cookie name beginning with the secure prefix is only accepted when set over HTTPS with the Secure attribute.

Both are enforced by the browser rather than by convention, so a misconfiguration results in the cookie being rejected rather than silently weakened.

Which makes the prefix a self-checking mechanism: if the cookie exists, its scope is correct.

They cost a rename and require no other change.

Open the browser's storage panel and read the Domain column for each cookie.

A value beginning with a dot, or naming the registrable domain rather than the host, is the wider scope.

Check which of those look session-related by name, since those are the ones that matter.

Request a static asset from a different subdomain and read the request headers to see which cookies travelled.

List your subdomains and identify which of them run software you do not control.

`cookies.domain_path` reports the scope of each cookie — host-only or domain-wide, root path or narrower.

`cookies.sensitive` identifies cookies whose name suggests a session or authentication role.

`cookies.inventory` builds the list from real Set-Cookie headers, and `cookies.size` measures the transfer cost of a widely scoped one.

`cookies.httponly`, `cookies.secure` and `cookies.samesite` report the attributes that matter alongside scope.

`cookies.javascript` is the coverage statement: cookies written by script after load are not in the HTTP inventory.