← All security check guides

Can someone else claim a subdomain?

A subdomain takeover starts with an ordinary piece of housekeeping that never happened. A name like blog.example.com was pointed at an external service with a CNAME record, the service was later cancelled or deleted, and the DNS record stayed behind. The name now points at a slot on somebody else's platform that nobody owns, and on most of those platforms the next person to register that slot gets to serve whatever they like from it.

What a dangling record costs

The damage is not that a page goes missing. It is that the page comes back, under somebody else's control, at an address that belongs to the domain. A browser shows the real domain in the address bar. A certificate authority will issue a valid certificate for the name, because whoever controls what it serves can pass the validation. Visitors see a padlock and a familiar address, and every instinct they have been taught says the page is genuine.

From there the reach depends on how the parent domain is set up, and it is usually wider than expected. Cookies scoped to the parent domain travel to every subdomain, so a session cookie set without a narrow scope is readable by the claimed name. Content Security Policies, CORS rules and OAuth redirect allowlists are frequently written to trust an entire domain and everything under it, which turns a stolen subdomain into a trusted origin. Email sent from the name inherits the domain's reputation.

The rest is reputation and search. A claimed subdomain is a favourite host for phishing pages aimed at the organisation's own customers, and for spam pages that borrow the domain's standing. Both are indexed under the real domain, and both are what a customer finds when they check.

Two facts, or it is not reported

This is the check where enthusiasm produces the most damage, because the alarming version of the sentence is easy to generate and almost always wrong. Any tool can list the CNAME records on a domain and announce that each one is a takeover risk. Most of those records point at a CDN, a help desk or a marketing platform that is working exactly as intended, and telling an owner that their support portal can be stolen because it runs on a hosted service teaches them to close the report.

CheckWeb reports a candidate only when two independent facts hold at once. The first is that the CNAME target belongs to a platform where an abandoned resource can genuinely be registered again by someone else. That list is curated from can-i-take-over-xyz, and it is shorter than the list of platforms that can hold a dangling record: providers that refuse a domain no account has proven it owns are left out entirely, because a record pointing at one of them is untidy rather than stealable.

The second is evidence that the slot is empty right now. Either the platform answers with its own unmistakable message for a resource that does not exist, or, on the platforms that release a hostname when the resource behind it is deleted, the target has stopped resolving altogether. A live site on the same platform produces neither, and produces no finding.

Nothing is ever registered to confirm any of this. Claiming a dangling resource is not a stronger check, it is the attack, and it would leave the scanner holding a name it has no right to and the owner holding an incident. Every request made here is a plain GET, on a connection that is structurally incapable of sending anything else.

How it looks in the report

The finding names the subdomain, the CNAME target, the provider, and the exact string the platform answered with. That last part is quoted rather than summarised because it is another company's error page, not the customer's data, and it is what turns a verdict into something checkable: two commands, one to read the DNS record and one to fetch the address, reproduce the whole finding independently.

Names are discovered from public certificate transparency logs and a list of common labels, and only names ending in the verified domain are ever looked up. Certificate logs are a public record of everybody's certificates, so that filter is what keeps the sweep from turning into an enumeration of other people's infrastructure.

It is a server-scope finding, which is a separate permission from the website scan: on shared hosting the machine and its DNS are not always one person's to grant. Like the rest of the active layer it runs after domain ownership is verified, and it appears in the private report and the PDF rather than on any public page.

Example

Subdomain takeover candidate: blog.example.com

blog.example.com points at a decommissioned service, and the platform confirms the slot is unclaimed. Until the DNS record is removed, anyone who registers that resource can serve their own content on the subdomain. Delete the record if the service is finished with, or re-create the resource so the name points at something owned.

FAIL

blog.example.com → old-bucket.s3.amazonaws.com (Amazon S3), answered "NoSuchBucket"

Dangling vs closed

Dangling

A campaign microsite was built on a hosted platform two years ago and pointed at with a CNAME. The subscription lapsed, the site was deleted, and nobody touched DNS. The record still resolves to the platform, the platform reports that no resource is configured for it, and the name that ran the campaign is now a free slot on somebody else's signup form.

Closed

The record was removed the same week the service was cancelled, so the name no longer resolves at all. Where the service is still wanted, the resource exists at the provider and answers with real content, which is a working configuration and not a finding regardless of how many CNAME records the domain carries.

Order matters when unwinding one: remove the DNS record first, then delete the resource at the provider. Deleting the resource first opens the window this page is about, and that window has been exploited within hours on domains that anyone was watching.

How to close it

  • Remove the DNS record for the name if the service behind it is finished with. This is the whole fix in most cases, and it is one deletion at whichever provider hosts the domain's DNS.
  • If the name is still wanted, re-create the resource at the provider so it points at something genuinely owned. Registering the slot again closes the window and restores the service in one step.
  • Check the rest of the zone while it is open. A dangling record is rarely alone: whatever process left one behind, usually a project that ended without a checklist, tends to have left several. Records pointing at platforms nobody at the organisation still uses are the ones to read first.
  • Narrow what a subdomain would inherit if one were ever claimed. Scope session cookies to the exact host that needs them rather than to the parent domain, list specific origins in CORS and OAuth redirect rules rather than wildcarding the domain, and keep Content Security Policy sources explicit. None of this prevents a takeover, and all of it decides how much a takeover is worth. (Content Security Policy covers the last of those.)
  • Make the deletion part of decommissioning rather than a thing to remember. Whoever cancels a service removes the DNS record in the same change, and the order is record first, resource second.
  • Then re-run the audit and confirm the name is gone. A DNS change propagates on its own schedule, and only a lookup from outside the network shows what the rest of the world is currently being told.

Run a free scan

The free passive scan grades headers, TLS and known CVEs on any site in about thirty seconds, with no signup. Verifying that a domain is owned adds the deep scan, which resolves the names under it and reports a takeover candidate only where the platform itself confirms the slot is empty.

Check my website

This one needs an active scan

A passive scan reads what a site shows every visitor, and this finding is not in that layer. It takes an active audit, run by the owner on a domain they have verified, to look where it hides.

How the deep audit works →

FAQ

Is every dangling CNAME a takeover risk?
No, and that distinction is most of the work. A record pointing at a platform that will not serve a domain until an account proves it owns it cannot be taken over, however long it dangles. The record is worth deleting for tidiness; it is not a finding, and CheckWeb does not report it as one.
Does the scan register the resource to prove the point?
Never. Claiming a dangling slot is the attack itself, and it would leave a name in the wrong hands and an incident on the owner's desk. The finding rests on a DNS answer and a single read-only request, and the client used for that request cannot send anything other than a GET.
The subdomain shows a 404. Is that a takeover?
Not on its own. A 404 is what a working site returns for a page that does not exist, and reading every one as a dangling record is how a scanner ends up flagging half the internet. What counts is the specific message a platform serves when no resource is configured at all, which is a different page from an ordinary not-found.
How are the subdomains found in the first place?
From public certificate transparency logs, which record every certificate ever issued for the domain, plus a short list of common labels. Only names ending in the verified domain are looked up, so the sweep stays inside the domain whose owner asked for it.
Which platforms are actually affected?
Hosted platforms where a resource name is first-come and a deleted resource frees it again: object storage buckets, static site hosting, app platforms, documentation and help-desk products. The list changes as providers add domain verification, which is why the check works from a curated catalogue with a recorded source rather than from a guess about a hostname.

Related checks

Browse recent public reports →