Home / Knowledge hub / Cookie scope
Knowledge hub
Cookie scope
The domain and path settings that decide which sites and pages receive a cookie.
What it means
Cookie scope is the set of rules that decide where a browser sends a cookie. The Domain attribute names the host and, when set, its subdomains. The Path attribute narrows it to part of the site. If Domain is left out, the cookie goes only to the exact host that set it.
People often assume a cookie set at app.example.com is private to that app. If it is set with Domain=example.com, the browser sends it to every subdomain, including the forgotten blog, the staging server and the marketing site run by a third party.
Why it matters
The wider the scope, the more systems can read or overwrite the cookie. A weakness on one subdomain, or a subdomain takeover, can expose the session of a main application. A neighbouring service can also set a cookie that shadows yours, as in cookie tossing.
It is easy to widen the scope by accident, usually to make single sign-on work between two sites, and hard to notice later. The exposure grows as a company adds subdomains, and a cookie shared with a loosely maintained one inherits its weakest security.
How it shows up
Check the Set-Cookie header for Domain and Path. Prefer host-only cookies, with no Domain attribute, for sessions. The __Host- prefix enforces this: it requires Secure, Path=/ and no Domain. See cookie prefixes. Where sharing is needed, use the narrowest parent you can and consider separate sign-in per site.
Do not treat Path as a security boundary. Script on one page of an origin can reach pages elsewhere on the same origin, so a path-limited cookie is not hidden from them. The same-origin policy sets the real limits. Review every subdomain that can receive the cookie as part of the same trust zone.
Questions people ask
Cookie scope, answered
What happens if Domain is not set?
The cookie becomes host-only: the browser sends it only to the exact host that set it, and not to subdomains. That is the tighter setting and the one you usually want for session cookies.
Setting Domain makes it wider.
Is Path a security control?
No. It only controls which URL paths receive the cookie in a request. Scripts on other pages of the same origin can still read it unless it is HttpOnly, and they can open those pages in a frame.
Use separate origins for real separation.
Can a subdomain read a cookie set for the parent?
Yes, if the cookie was set with a Domain attribute covering it, the browser sends it there. The subdomain can also overwrite it.
That is why subdomain takeovers are so serious for cookie-based sessions.
What is the __Host- prefix?
It is a cookie name prefix that browsers enforce: the cookie must be Secure, set from a secure page, have Path=/ and no Domain. That guarantees it is host-only and cannot be set by a sibling.
It is a strong default for session cookies.
How do we review our cookie scope?
List every cookie your app sets, with its Domain, Path and flags, and list every subdomain that falls inside the Domain. Ask who controls each of them.
Narrow anything wider than it needs to be.
Sources
Where this comes from
Related
Terms that sit next to this one
Cookie tossing
A sibling subdomain planting cookies that your main site then trusts.
Cookie prefix
A name prefix such as __Host- that makes browsers enforce stricter cookie rules.
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
Subdomain takeover
Claiming an abandoned cloud resource that one of your DNS names still points to.
SameSite cookie
A cookie setting that limits when a browser sends it on requests from other sites.
Who else receives your cookie?
We check the scope of the cookies your app sets and whether a neighbouring subdomain could read or replace them, then report what we proved with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.