An attacker who controls one of your subdomains can serve content under your name, and may read or set cookies shared across your domain. They can also host convincing phishing pages and, in some setups, pass checks that trust your domain. The damage depends on how much your applications trust sibling subdomains.
Why a subdomain is not a small thing
Browsers treat app.example.com and old.example.com as different origins, but several features treat them as related. Cookies are the main one. MDN explains that a cookie set with the Domain attribute is available on that domain and its subdomains. Omit the attribute and the cookie goes to the host that set it, and to no sibling. So a session cookie scoped to the parent domain can be read by a server on any sibling subdomain, including one an attacker now runs.
MDN also warns that a subdomain can set a cookie for the parent domain, which can be abused in session fixation, and suggests cookie prefixes as a defence in depth measure.
What becomes possible
| Capability | How it works |
|---|---|
| Cookie theft | A parent scoped cookie is sent to the attacker's server when a user visits the hijacked subdomain |
| Session fixation | The attacker sets a cookie that your main app later accepts |
| Phishing under your name | A login page on a real company hostname looks trustworthy and may carry a valid certificate |
| Script injection | If your pages load scripts from the subdomain, the attacker's code runs inside them |
| Policy bypass | Content security policies that allow *.example.com also allow the hijacked host |
| Mail abuse | Records on the subdomain can be used in impersonation and, if relaxed alignment applies, may help spoofed mail pass checks |
Microsoft's guidance on dangling DNS lists cookie harvesting and brand damage among the risks of a takeover, alongside loss of control of the content.
Which of your settings widen the blast radius
- Session cookies with the Domain attribute set to the apex.
- Content security policies and CORS allowlists that use wildcard subdomains.
- OAuth redirect allowlists that trust any host under your domain. See our redirect URI validation checklist.
- Single sign on that trusts a shared parent domain cookie.
- DMARC with relaxed alignment and delegated subdomains. The DMARC specification itself advises care about delegating control of subdomains and mentions strict alignment as an option. See relaxed versus strict alignment.
How to shrink the impact
- Scope cookies narrowly. Leave out the Domain attribute where you can, so the cookie stays on one host.
- Use the host prefix. The prefixed cookie name forces a secure cookie with no Domain attribute. Our cookie prefix guide shows when to use it.
- Name hosts, not wildcards, in CSP, CORS and OAuth allowlists.
- Keep user content on a separate registrable domain, so a takeover there cannot reach your session cookies.
- Remove dangling records. Follow the audit steps.
A short incident outline
If you discover a takeover: remove or repoint the record, rotate sessions that may have been exposed, check what content was served and for how long, review certificate issuance logs for the hostname, and tell users if credentials could have been captured. Keep timestamps.
For the software side of your estate, Safeguard offers SBOM and dependency scanning with reachability analysis. A free scan is at gold.safeguard.sh/scan.
Quick check
Does HTTPS stop a subdomain takeover?
No. The attacker can often obtain a valid certificate for a hostname they control through your DNS, so the padlock proves nothing about who is behind it.
Is a cookie without a Domain attribute safe from this?
It is not sent to sibling subdomains, which removes the main theft path. A sibling can still try to set a cookie for the parent, so prefixes help too.
Sources
- MDN, Subdomain takeover
- MDN, Using HTTP cookies
- Microsoft Learn, Prevent dangling DNS entries and avoid subdomain takeover
- RFC 9989, DMARC
Last reviewed: 19 October 2026.
