Subdomain Takeover
debt(d5/e3/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list specialist tools subjack, can-i-take-over-xyz, and dnsx — these are purpose-built scanners, not default linters or compiler checks. Dangling DNS records are invisible in normal operation and won't surface without dedicated tooling or a deliberate audit process.
Closest to 'simple parameterised fix' (e3). The quick_fix is to audit all CNAME records and remove those pointing to deprovisioned services. This is a targeted DNS-level cleanup — more than a single-line patch since it requires identifying and removing multiple records across a DNS zone, but it doesn't require touching application code across multiple files. Establishing an ongoing audit process adds modest organisational overhead but is still localised.
Closest to 'persistent productivity tax' (b5). The applies_to is 'any' context, meaning every cloud service decommissioning event across the organisation carries this risk. Without a DNS inventory and audit process, subdomains accumulate over years (per common_mistakes), creating a persistent operational tax on every infrastructure change. It doesn't reshape every line of code, but it burdens every deprovisioning workflow.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception states developers believe only high-traffic subdomains matter, but an attacker controlling any subdomain can set cookies for the parent domain, bypass CORS/CSP wildcard policies, and run phishing under the brand. This is a widely held wrong belief — the blast radius is far larger than most developers intuit, and the impact extends across the entire domain, not just the taken-over subdomain.
Also Known As
TL;DR
Explanation
Subdomain takeover occurs when a DNS CNAME record points to a third-party platform (GitHub Pages, Heroku, AWS S3, etc.) and the target resource has been deprovisioned without removing the DNS record. An attacker who registers the now-available resource on that platform gains control over the subdomain, enabling phishing, cookie theft (if the subdomain shares a parent domain cookie), and content injection. Prevention: always delete DNS records before deprovisioning services, and perform regular DNS audits.
Common Misconception
Why It Matters
Common Mistakes
- Not removing DNS records when deprovisioning cloud resources — the CNAME remains pointing at nothing.
- No DNS audit process — subdomains accumulate over years with no inventory.
- Not monitoring for dangling DNS records — tools like aquatone detect these automatically.
- Forgetting that subdomains can read cookies set on the parent domain — a takeover affects the whole domain.
Avoid When
- Never leave CNAME records pointing to decommissioned Heroku, S3, GitHub Pages, or Azure endpoints — they are claimable by anyone.
- Do not delay DNS cleanup after retiring a service — dangling records can be exploited within minutes of resource deletion.
When To Use
- Audit DNS records whenever decommissioning a service — remove CNAME records pointing to deleted cloud resources immediately.
- Use automated tools (SubFinder, can-i-take-over-xyz) to detect dangling DNS records in CI or periodic scans.
Code Examples
# Dangling CNAME — subdomain takeover risk:
# DNS: staging.example.com CNAME myapp-staging.herokuapp.com
# Heroku app deleted — CNAME still exists
# Attacker creates Heroku app at same hostname
# staging.example.com now serves attacker content
# Fix: remove DNS record when deprovisioning any cloud resource# Dangling CNAME → unclaimed service = subdomain takeover
# staging.yourapp.com CNAME → yourapp.github.io (page deleted)
# Attacker claims yourapp.github.io → controls staging subdomain
# Prevention:
# 1. Remove DNS records BEFORE deprovisioning the service
$ dig staging.yourapp.com CNAME
# Verify you still own the pointed resource
# 2. Automate with subjack in CI:
$ subjack -w subdomains.txt -t 100 -o results.txt
# 3. Check can-i-take-over-xyz list for vulnerable providers:
# https://github.com/EdOverflow/can-i-take-over-xyz
# 4. For GitHub Pages, S3, Heroku:
# Delete DNS record first, then deprovision the service