DEV Community

Cover image for Top 10 Services Most Vulnerable to Subdomain Takeover (And How to Detect Them)
Mika
Mika

Posted on

Top 10 Services Most Vulnerable to Subdomain Takeover (And How to Detect Them)

#security #webdev #cybersecurity

Subdomain takeovers are one of the most underrated vulnerabilities in web security. They're easy to miss, surprisingly common, and can have serious consequences — phishing pages served under your own domain, session cookie theft, or brand damage.

The attack always follows the same pattern: a subdomain points to an external service via a CNAME record, the service gets deprovisioned, but nobody removes the DNS record. The subdomain is now dangling — and claimable by anyone.

Here are the 10 services where this happens most often, along with the fingerprint that gives it away.

1. GitHub Pages

Fingerprint: There isn't a GitHub Pages site here

GitHub Pages is one of the most common culprits. Developers frequently set up docs.example.com or blog.example.com pointing to a GitHub Pages site, then delete the repository or disable Pages without removing the CNAME record.

Anyone can create a GitHub Pages site at the dangling address and immediately serve content under your subdomain.

Example CNAME chain:

docs.example.com → username.github.io → ❌ unclaimed
Enter fullscreen mode Exit fullscreen mode

2. Heroku

Fingerprint: No such app

Heroku is a classic. Staging environments, side projects, and old prototypes frequently get deleted while their DNS records live on. The "No such app" page is one of the most recognizable takeover signals in bug bounty hunting.

Example CNAME chain:

staging.example.com → old-app.herokuapp.com → ❌ unclaimed
Enter fullscreen mode Exit fullscreen mode

3. AWS S3

Fingerprint: NoSuchBucket

S3 buckets configured for static website hosting are highly susceptible. When a bucket is deleted, the subdomain pointing to it becomes claimable by anyone who creates a new bucket with the same name in the same region.

This one is particularly dangerous because S3 buckets can serve arbitrary files — including HTML pages and scripts.

Example CNAME chain:

assets.example.com → example-assets.s3-website-us-east-1.amazonaws.com → ❌ bucket deleted
Enter fullscreen mode Exit fullscreen mode

4. Vercel

Fingerprint: The deployment could not be found

Vercel deployments are spun up and torn down constantly. When a project gets deleted or a custom domain gets removed from a Vercel project without cleaning up DNS, the subdomain dangles.

Example CNAME chain:

app.example.com → cname.vercel-dns.com → ❌ project deleted
Enter fullscreen mode Exit fullscreen mode

5. Netlify

Fingerprint: Not Found - Request ID

Same story as Vercel. Netlify sites get deleted all the time — marketing landing pages, campaign microsites, A/B test variants. The DNS record outlives the site.

Example CNAME chain:

landing.example.com → example.netlify.app → ❌ site deleted
Enter fullscreen mode Exit fullscreen mode

6. Azure

Fingerprint: 404 Web Site not found

Azure has multiple vulnerable services — App Service, Front Door, CDN, Traffic Manager. Enterprise companies running on Azure often have dozens of subdomains pointing to Azure resources, and decommissioning processes don't always include DNS cleanup.

Example CNAME chain:

portal.example.com → example.azurewebsites.net → ❌ app deleted
Enter fullscreen mode Exit fullscreen mode

7. Shopify

Fingerprint: Sorry, this shop is currently unavailable

E-commerce businesses frequently set up custom subdomains for their Shopify stores — shop.example.com or store.example.com. When they migrate platforms or shut down the store, the CNAME often stays.

Example CNAME chain:

shop.example.com → example.myshopify.com → ❌ shop closed
Enter fullscreen mode Exit fullscreen mode

8. Zendesk

Fingerprint: Help Center Closed

Support portals are a goldmine for subdomain takeovers. Companies set up help.example.com or support.example.com pointing to Zendesk, then migrate to a different support platform without cleaning up DNS.

A takeover here is particularly dangerous — users trusting a support subdomain might enter credentials or sensitive information.

Example CNAME chain:

help.example.com → example.zendesk.com → ❌ account closed
Enter fullscreen mode Exit fullscreen mode

9. Ghost / Ghost.io

Fingerprint: Domain not configured

Ghost is a popular blogging platform. blog.example.com pointing to a Ghost instance is extremely common, and when companies rebrand or migrate their blog, the DNS record is often forgotten.

Example CNAME chain:

blog.example.com → example.ghost.io → ❌ site not configured
Enter fullscreen mode Exit fullscreen mode

10. Fastly

Fingerprint: Fastly error: unknown domain

CDN takeovers are less common but high impact. Fastly serves content for massive amounts of web traffic, and a dangling CNAME to a Fastly endpoint means an attacker could potentially intercept or serve content to users expecting your site.

Example CNAME chain:

cdn.example.com → example.global.ssl.fastly.net → ❌ service not configured
Enter fullscreen mode Exit fullscreen mode

How to detect these vulnerabilities

Detection comes down to two things:

1. Check for NXDOMAIN
Follow the full CNAME chain. If the final destination returns NXDOMAIN — the domain doesn't exist in DNS — you have a dangling CNAME regardless of the service.

2. Check for service fingerprints
If the target resolves but returns one of the error messages above, the service exists but isn't configured for that domain. That's your takeover signal.

You can check any subdomain automatically using SubdomainChecker — it follows CNAME chains, checks fingerprints against 80+ services, and even enumerates subdomands from certificate transparency logs so you don't have to find them manually.

There's also a free API if you want to integrate takeover detection into your own recon pipeline: RapidAPI

How to protect yourself

  1. Keep a DNS inventory — know what every subdomain points to
  2. Remove DNS records before decommissioning services — DNS cleanup should be step one, not an afterthought
  3. Audit regularly — run a takeover check every few months, especially after infrastructure changes
  4. Automate it — use the API to run checks automatically as part of your CI/CD pipeline or security monitoring

Subdomain takeovers are preventable. The vulnerability only exists because of forgotten DNS records — and a 30-second check is all it takes to find them.

Top comments (0)