You shut down a product. You deleted the Heroku app, tore down the S3 bucket, and removed the Netlify site. But you probably forgot the DNS record pointing to it.
That subdomain is now up for grabs.
The problem with dangling DNS records
When you create staging.yourapp.com and point it to Heroku, you add a CNAME record mapping your subdomain to yourapp.herokuapp.com. When you shut down the app, that CNAME stays behind. Heroku lets anyone register a new app at that same .herokuapp.com address. If an attacker grabs it, they now control everything that loads on staging.yourapp.com. It runs under your domain, with your SSL cert, and with your brand name sitting right there in the address bar.
You probably didn't notice because you were busy shipping the next thing.
Why this is actually dangerous
This isn't a theoretical edge case. It's happened to Uber, Microsoft, and it keeps happening to smaller startups that never bother to audit their DNS. Once someone controls a subdomain, the rest is easy:
-
Phishing: A login page at
staging.yourapp.comlooks completely legitimate. There are no browser warnings and the HTTPS is valid. -
Cookie theft: Session cookies scoped to
.yourapp.comare readable by any subdomain, including the one they just claimed. -
CSP bypass: If your Content Security Policy whitelists
*.yourapp.com, the attacker is basically inside the house. Any scripts they serve will count as trusted.
Your browser has absolutely no way of knowing the subdomain changed hands.
Where to look
Any external hosting platform can be a vector. The most common culprits I see are Heroku (app deleted but CNAME stays), GitHub Pages (repo renamed), Netlify, and S3. Fastly, Pantheon, Azure, and Shopify all have the exact same problem. There's a solid community-maintained list at github.com/EdOverflow/can-i-take-over-xyz that tracks exploitable platforms and their specific error fingerprints.
How to check if you're vulnerable
Most teams don't have a full list of their subdomains. You'll need to export your DNS provider's zone file and read through it. Check old CI/CD configs for anywhere you set a CNAME. Finally, hit up crt.sh (certificate transparency logs) to see every subdomain you've ever issued a cert for:
curl "https://crt.sh/?q=%.yourapp.com&output=json" | jq '.[].name_value' | sort -u
Once you have your list, check if the target still exists for each CNAME:
dig CNAME staging.yourapp.com
curl -I https://yourapp.herokuapp.com
If dig returns a CNAME and curl gets a "No such app" or a 404, that's a dangling record. Someone could claim it right now. Also, make sure to check your A records. If you're pointing at an elastic IP that you've decommissioned, that IP might be sitting in a stranger's AWS account.
Fixing it
The fix is incredibly straightforward: just delete the DNS record.
The much harder part is making sure this doesn't keep happening. DNS cleanup usually doesn't make it onto shutdown checklists, but it needs to be treated with the same urgency as revoking API keys. When you decommission a service, delete the DNS record that same day and verify it no longer resolves. If you absolutely need to keep the subdomain, point it at something you control. Even a static page returning a 200 is enough to block a takeover.
Tools I use for this
-
ZeroHook (
zerohook.org) for auditing DNS and subdomains in one place. It automatically flags dangling records and has a free tier. - crt.sh as a starting point for discovery.
- subjack to automatically scan a list of subdomains for takeover vulnerabilities.
- dnsx for fast bulk DNS resolution when the list gets long.
TL;DR
DNS records outlive the services they point to. That's the entire problem.
Check your subdomains, especially the old ones. If you've never audited your zone file, take 20 minutes and do it this week. You'll almost certainly find something. It's a five-minute fix if you catch it early, and a full-blown incident if you don't.
Top comments (0)