Leave the Domain attribute off unless you must share a cookie across subdomains. Without it, the cookie is host-only and goes only to the host that set it. With it, the cookie goes to that domain and all its subdomains, so a weak subdomain can read or influence it.
What Domain does
MDN states that setting Domain makes the cookie available to that domain and all its subdomains. If omitted, the cookie is returned only to the host that sent it, a host-only cookie. MDN calls this more restrictive, because the cookie is not available to subdomains of that host.
Rules for a valid value: it must be the server's own domain or a parent of it, and never a public suffix such as com, co.uk or github.io. A leading dot is ignored. If a Domain is specified, subdomains are always included.
| Setting | Sent to | Risk |
|---|---|---|
| No Domain | Only the setting host | Smallest exposure |
| Domain=example.com | example.com and every subdomain | Any subdomain, including forgotten ones, receives it |
Why host-only is safer
Imagine a session cookie for app.example.com with Domain=example.com. A blog, an old test site or a vendor hosted help page on another subdomain now receives that cookie on every request. A cross-site scripting bug in any of them, or a subdomain takeover, can expose the session.
The related cookie prefixes help. Per MDN, a __Host- cookie must be set with Secure from an HTTPS page, must not have a Domain attribute, and must have Path set to /. This makes it sent only to the host that set it and not overridable on any path. The __Host-Http- form adds HttpOnly, and MDN notes browsers without prefix support will simply accept such cookies, so do not rely on the prefix alone.
The Path misconception
Developers sometimes use Path to hide a cookie from other apps on the same host. MDN says Path is not intended as a security measure and does not protect against unauthorised reading of the cookie from a different path. Separate sensitive apps by origin, not by path.
A decision guide
- Does only one hostname need the cookie? Omit Domain and consider a
__Host-name. - Do two subdomains truly share a login? Set Domain to the parent, and audit every subdomain under it first.
- Is the cookie sensitive? Prefer a separate session per host and a token exchange, rather than a shared cookie.
- Does any subdomain run third-party or user generated content? Do not share a session cookie with it.
An inventory step helps. List every DNS record under your domain, decide which ones would see a shared cookie, and retire dangling records that could be taken over.
For flags beyond Domain, see secure cookie flags explained and cookie prefixes decision guide.
Quick check
Does Domain=example.com include www.example.com?
Yes. MDN says subdomains are always included when a domain is specified.
Can I set a cookie for a different registered domain?
No. The value must be the sending server's domain or a parent of it, and cookies that break the rules are ignored.
Safeguard's asset discovery helps teams list the services and hosts they run, and its dependency scan checks the libraries behind them. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
