What it is
A subdomain takeover happens when a DNS record (often a CNAME) still points at a third-party service that no longer owns the resource. An attacker can register the abandoned name on that service and start serving content on your subdomain.
Why it matters
A working subdomain under your brand can host phishing pages, set cookies on your origin, or bypass CORS and SSO trust boundaries. The fix is cheap, but the reputational and security damage from a successful takeover is not.
How it is exploited
An attacker scans your DNS for CNAME or NS records that still point at S3 buckets, Heroku apps, GitHub Pages, or SaaS hostnames you no longer own. They re-register the target name on that provider and immediately serve their own content under your subdomain. From there they run phishing pages on a trusted hostname, set or read same-site cookies that your auth flows trust, and trade on your brand to harvest credentials.
How to fix it
- Inventory dangling CNAMEs. Pull every CNAME and ALIAS record across your DNS zones and resolve them. Flag any that point at S3 buckets, Azure resources, Heroku apps, GitHub Pages, or SaaS hostnames that no longer respond or return a clear unclaimed banner.
- Remove the dangling records. Delete DNS entries that point at services you no longer use. Removing the record is the safest action because it immediately closes the takeover window.
- Reclaim upstream services you still need. If the subdomain is still in use, recreate or rename the resource at the upstream provider before re-pointing DNS. Verify the new resource answers on the expected hostname before flipping production traffic.
- Monitor continuously. Schedule recurring scans for new dangling records so future cleanups do not reintroduce risk. Wire the alerts into the same channel your platform team already watches for DNS changes.