Check for subdomain takeover risk

30 min Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

If you have a DNS record (usually a CNAME) pointing your subdomain at a third-party service you've since stopped using — a deleted Heroku app, an unclaimed AWS S3 bucket, an old GitHub Pages site — anyone can often claim that exact service name and effectively take over your subdomain, serving whatever content they want from what looks like your own domain.

A subdomain with a CNAME still pointing to a cloud service you've stopped using — a deleted Heroku app, an unclaimed GitHub Pages site — can often be claimed by anyone, letting them serve content from your own subdomain.

The full picture

Subdomain takeover risk arises when a DNS record points to a third-party service — a hosting platform, a content delivery network, or similar external service — that's no longer actually configured or claimed on that service's side, creating a window where an attacker can claim that same service configuration and effectively take control of content served under your legitimate subdomain.

This represents a genuinely serious vulnerability specifically because the resulting malicious content appears to be served from your legitimate domain, since the DNS record itself still points to your subdomain — a visitor has no obvious way to distinguish this attacker-controlled content from anything else genuinely hosted under your domain.

This risk typically emerges through a common, easy-to-overlook oversight — a service or integration gets decommissioned or migrated away from, but the corresponding DNS record pointing to that now-unclaimed service configuration never gets removed or updated, leaving this dangling reference available for an attacker to discover and claim.

Identifying this risk requires genuinely auditing your DNS records against your actual, currently active third-party service configurations — any DNS record pointing to a service you've discontinued or migrated away from represents a potential vulnerability worth immediate remediation, either by removing the unnecessary record or by reclaiming the corresponding service configuration if the subdomain remains genuinely needed.

How to fix it

1

Audit every subdomain's DNS records

List every CNAME and A record pointing to third-party services (cloud hosts, page builders, app platforms).
2

Confirm each target service is actually still active

For each subdomain, visit the service it points to directly and confirm it resolves to YOUR content, not an error page or "not claimed" message.
3

Remove DNS records for anything no longer in use

If a subdomain points to a service you decommissioned, delete that DNS record entirely rather than leaving it dangling.
4

Re-check periodically

This risk resurfaces any time you stop using a third-party service without cleaning up the DNS record that pointed to it.

Common mistakes

This is easy to overlook because the subdomain still 'resolves' — it just resolves to nothing you control, and often shows nothing suspicious until someone actually claims it.