What is Subdomain Takeover? How It Happens and How to Prevent It

Introduction

A subdomain takeover happens when your DNS still points to a third-party service, but the resource behind that service is no longer owned or claimed by your organization.

The DNS record keeps working. The browser still shows your subdomain. But the content may be served by a resource that no longer belongs to you, or by a resource that could be claimed by someone else depending on the platform.

This is why subdomain takeover is more than a defacement issue. A trusted subdomain can affect phishing credibility, cookie scope, OAuth redirect trust, CORS assumptions, brand trust, and customer confidence.

This guide explains how subdomain takeover works, how dangling CNAME and A records create risk, how to treat platform fingerprints safely, how to validate candidates without creating new risk, and how to prevent the issue through DNS lifecycle controls.

What subdomain takeover actually is

Subdomain takeover is a DNS lifecycle failure. A subdomain continues to point to a service that was deleted, moved, unpublished, downgraded, or disconnected from your account.

The most common pattern is a CNAME record pointing to a third-party platform such as a hosting provider, CDN, help center, status page, cloud service, or preview deployment platform.

When the third-party resource is removed but the DNS record remains, the subdomain becomes a dangling DNS record. If the provider allows another account to claim the same resource, custom hostname, or target name, the subdomain may become takeoverable.

The important word is may. Provider behavior changes over time. Some providers require domain verification, some reserve names after deletion, some block reuse, and some only expose a harmless error page. A fingerprint is a candidate, not proof of exploitability.

How subdomain takeover works at the DNS level

A CNAME record tells DNS that one hostname is an alias for another hostname. For example, help.example.com may point to example-help.vendorapp.com.

When a user visits help.example.com, the resolver follows the CNAME target and reaches the third-party platform. The browser address bar still shows help.example.com because that is the hostname the user requested.

If the vendor resource exists and is owned by your account, the setup is normal. If the resource was deleted but the DNS record remains, the platform may return an error page that indicates the resource is not currently claimed.

The takeover risk appears only when that unclaimed state can be claimed by another account or tenant. That depends on the provider, the resource type, domain verification rules, hostname validation, and current platform protections.

The three states of dangling DNS risk

Every third-party CNAME should be reviewed as one of three states: active and owned, dangling candidate, or confirmed owned by the wrong party.

This state model helps avoid false positives. Do not treat every vendor error page as a confirmed takeover.

• State 1: active and owned — The CNAME points to a third-party resource that exists and is owned by your organization. Requests return expected content, and the vendor console confirms the resource belongs to your account.

  # DNS record
  status.example.com. IN CNAME example.statuspage.io.
  
  # Defensive check
  dig CNAME status.example.com +short
  curl -I https://status.example.com
  
  # Validate in the vendor console:
  # Resource exists, custom domain is configured, and ownership is confirmed.

• State 2: dangling candidate — The CNAME still exists, but the third-party platform returns an error page, missing-resource response, or default page. This is a candidate that needs manual validation. It is not automatically exploitable.

  # DNS record still exists
  old-help.example.com. IN CNAME example-help.vendorapp.com.
  
  # Candidate check
  dig CNAME old-help.example.com +short
  curl -I https://old-help.example.com
  
  # Next step:
  # Check provider documentation and your vendor console.
  # Confirm whether the resource is owned, deleted, reserved, or claimable.

• State 3: confirmed ownership problem — The subdomain serves content from a resource that is not owned by your organization, or the provider confirms the resource/custom hostname can be claimed by another tenant. Treat this as urgent DNS exposure.

  # Do not claim third-party resources as a validation step unless you are operating
  # under an approved internal security process.
  
  # Safer validation path:
  # 1. Confirm the DNS target.
  # 2. Check the provider console.
  # 3. Check provider domain-verification status.
  # 4. Remove the DNS record or reclaim the resource under your organization account.
  # 5. Retest from an external network.

Common platform fingerprints to investigate

Many platforms return recognizable error messages when a custom hostname points to a missing or unconfigured resource. These messages are useful for detection, but they are not proof of takeover by themselves.

Treat platform fingerprints as investigation leads. Confirm current provider behavior, domain verification requirements, hostname ownership rules, and whether the specific resource is actually claimable before assigning severity.

Provider behavior changes. GitHub Pages, Heroku, Azure, Shopify, Fastly, Netlify, S3, and other platforms have introduced different protections, account verification requirements, hostname verification flows, or reuse controls over time.

• GitHub Pages — GitHub Pages can be relevant when a custom domain still points to GitHub Pages but the Pages site, repository, or custom-domain configuration is no longer linked correctly. GitHub recommends verifying custom domains to reduce takeover risk.

  # Candidate check for an owned domain
  
  dig CNAME blog.example.com +short
  curl -I https://blog.example.com
  
  # If the response suggests a missing GitHub Pages site,
  # verify ownership in GitHub Pages settings before marking it exploitable.

• Heroku — Heroku custom domains can create dangling-DNS risk when an app or custom domain is removed while DNS remains. Heroku has also introduced mitigations and account verification requirements, so check current Heroku behavior before treating a finding as confirmed.

  # Candidate check for an owned domain
  
  dig CNAME old-app.example.com +short
  curl -I https://old-app.example.com
  
  # Confirm in Heroku dashboard or API whether the custom domain
  # is still attached to an app owned by your organization.

• Azure App Service and Azure resources — Azure documents dangling DNS records as a subdomain takeover risk and recommends removing DNS records before deleting resources, using custom domain verification, and reviewing dangling DNS exposure.

  # Candidate check for an owned domain
  
  dig CNAME app.example.com +short
  curl -I https://app.example.com
  
  # Confirm in Azure whether the target resource exists,
  # whether the hostname is verified, and whether the DNS record should remain.

• Fastly and CDN services — CDN platforms may show an unknown-domain or service-not-configured response when the hostname is not attached to an active service. This can indicate a candidate, but provider-side hostname ownership controls must be checked.

  # Candidate check for an owned domain
  
  dig CNAME assets.example.com +short
  curl -I https://assets.example.com
  
  # Confirm in the CDN console whether the hostname is configured
  # under your organization account.

• Shopify and commerce platforms — Commerce platforms may display an unavailable-store or unconfigured-domain response when a custom domain points to the platform but is not attached to an active store. Confirm ownership and current platform rules before marking it exploitable.

  # Candidate check for an owned domain
  
  dig CNAME shop.example.com +short
  curl -I https://shop.example.com
  
  # Confirm in the commerce platform console whether the domain
  # belongs to your store/account.

• Cloud storage and static hosting — S3-style static hosting, blob storage, and other object-storage website endpoints can create dangling-DNS risk when a DNS record points to a deleted bucket, container, or static site endpoint. Behavior depends on provider naming and ownership rules.

  # Candidate check for an owned domain
  
  dig CNAME static.example.com +short
  curl -I https://static.example.com
  
  # Confirm in the cloud account whether the bucket/container/static site
  # exists and is owned by your organization.

Why subdomain takeover matters

The most obvious impact is content control: a user visits a subdomain that appears to belong to your organization and sees content that your organization did not publish.

The deeper impact depends on how your domain is used. A taken-over subdomain can make phishing more believable because the page appears under a trusted domain. It can also affect OAuth redirect assumptions, SSO trust models, CORS allowlists, cookie scoping, and brand reputation.

The risk is highest when sensitive systems trust every subdomain under the parent domain. If the parent application assumes all subdomains are controlled and safe, one dangling DNS record can become a trust boundary failure.

This is why subdomain takeover findings should include context: hostname, provider, target, ownership evidence, affected trust relationships, cookie scope, authentication flows, and whether the service is customer-facing.

Cookie and CORS risk explained safely

Cookie and CORS risks are real, but they need precise wording. A subdomain takeover does not automatically steal sessions or bypass APIs. The impact depends on how cookies and cross-origin trust are configured.

If a sensitive cookie is set with Domain=example.com, browsers include subdomains in the cookie scope. A taken-over subdomain may receive that cookie in requests depending on attributes such as Secure, HttpOnly, SameSite, Path, and host scoping. Leading dots are not the key distinction in modern browsers; parent-domain scoping is.

HttpOnly prevents JavaScript from reading a cookie through document.cookie, but the browser may still attach the cookie to matching requests. That is why sensitive session cookies should usually be host-only unless parent-domain sharing is required.

CORS risk usually comes from server-side allowlist logic. The unsafe pattern is not a literal Access-Control-Allow-Origin: *.example.com header. Browsers do not treat that as a wildcard subdomain allowlist. The real risk is application code that dynamically reflects any Origin ending in .example.com while also allowing credentials.

Defensive review should ask two questions: are sensitive cookies scoped only to the hosts that need them, and do credentialed CORS policies trust broad subdomain patterns?

• Risk pattern: broad cookie scope — A sensitive session cookie scoped to the parent domain may be included for subdomains. Prefer host-only cookies for sensitive sessions when possible.

  # Riskier pattern for sensitive sessions
  Set-Cookie: session=...; Domain=example.com; Secure; HttpOnly; SameSite=Lax
  
  # Safer host-only pattern
  Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax
  
  # Host-only means no Domain attribute is set.

• Risk pattern: dynamic CORS trust — The risky implementation is server-side logic that reflects broad subdomain origins while allowing credentials. Review code and gateway rules for this pattern.

  # Risky logic pattern to review defensively
  # If Origin ends with .example.com, reflect it as Access-Control-Allow-Origin
  # and also set Access-Control-Allow-Credentials: true
  
  # Safer pattern
  # Maintain an explicit allowlist of exact trusted origins.
  # Do not trust every subdomain automatically.

How to detect subdomain takeover candidates safely

Detection has two stages. First, enumerate subdomains and DNS records. Second, check whether CNAME targets or service endpoints point to missing, unowned, or unconfigured resources.

Run these checks only against domains you own or have explicit authorization to assess. Automated takeover templates should be treated as candidate detection, not final proof.

• Step 1: build a subdomain list — Use multiple discovery sources. Certificate transparency logs are useful, but they are not a complete inventory. Combine them with DNS inventory, cloud inventory, passive DNS, and EASM results.

  # Certificate transparency discovery for an owned domain
  curl -s 'https://crt.sh/?q=%.example.com&output=json' | \
    jq -r '.[].name_value' | sort -u > subdomains.txt
  
  # Add your DNS provider export and cloud inventory where possible.

• Step 2: extract CNAME records — Resolve the subdomain list and identify hostnames that point to third-party platforms.

  # Resolve CNAMEs for owned subdomains
  cat subdomains.txt | dnsx -silent -cname -resp > cname-records.txt
  
  # Review third-party targets manually
  cat cname-records.txt

• Step 3: run fingerprint checks as candidate detection — Tools such as nuclei can help identify known missing-resource fingerprints. Treat output as candidates requiring validation, not confirmed vulnerabilities.

  # Authorized testing only
  nuclei -l subdomains.txt -t takeovers/ -silent -o takeover-candidates.txt
  
  # Next step:
  # Manually confirm provider behavior, account ownership, and resource state.

• Step 4: validate candidates without creating new risk — Do not claim a third-party resource unless you are operating under an approved internal security process. Prefer provider-console validation, vendor support confirmation, DNS cleanup, or reclaiming the resource under your organization account.

  # Safe validation checklist
  # 1. Confirm the CNAME target.
  # 2. Confirm the provider and resource type.
  # 3. Check your organization account for the resource.
  # 4. Check provider docs for domain verification and reuse rules.
  # 5. Remove the DNS record if unused.
  # 6. Reclaim the resource only under your organization account if the subdomain is still needed.

• Step 5: document confidence level — Separate confirmed findings from needs-validation items. This prevents over-reporting and helps engineering teams prioritize real exposure.

  # Suggested finding states
  # confirmed: resource is unowned or owned by the wrong account
  # candidate: fingerprint suggests missing resource; provider behavior not yet confirmed
  # safe: resource is active and owned by your organization
  # stale-safe: DNS removed or resource reclaimed

What vulnerable and safe configurations look like

The vulnerable state is usually simple: DNS points to a service lifecycle that your organization no longer controls.

The fix is also simple once ownership is clear: remove the DNS record or ensure the target resource is owned by your organization.

• Vulnerable pattern: DNS outlives the service — A subdomain still points to a deleted or disconnected third-party resource. The platform returns a missing-resource page or unconfigured-hostname response.

  # Vulnerable pattern
  old-app.example.com. IN CNAME example-old-app.vendorhost.com.
  
  # The vendor resource was deleted, unpublished, or disconnected.
  # DNS was not removed.

• Safe pattern: remove unused DNS — If the subdomain no longer has a business purpose, delete the DNS record and verify that it no longer resolves.

  # After removal
  
  dig CNAME old-app.example.com +short
  
  # Expected:
  # no CNAME response, or NXDOMAIN depending on zone configuration

• Safe pattern: reclaim or recreate under your account — If the subdomain still needs to exist, the target resource should be recreated, reattached, or reclaimed under your organization account and verified in the provider console.

  # Safe remediation checklist
  # 1. Create or restore the resource under your organization account.
  # 2. Attach the custom hostname.
  # 3. Complete provider domain verification if required.
  # 4. Serve a placeholder, redirect, or intended content.
  # 5. Retest externally.

• Defense-in-depth: add CAA records — CAA records can limit which certificate authorities may issue for your domain. They do not fix dangling DNS and do not prevent takeover by themselves. The real fix is removing the dangling record or owning the target resource.

  # Example CAA policy
  example.com. IN CAA 0 issue "letsencrypt.org"
  example.com. IN CAA 0 issuewild ";"
  
  # Check CAA
  dig CAA example.com

Prevention: the decommissioning process

Most subdomain takeovers are created during decommissioning. A team deletes a vendor resource, cloud service, preview app, or static site, but the DNS record stays behind.

Fixing the process is more important than running one cleanup scan. DNS cleanup must be part of service shutdown, vendor offboarding, cloud migration, and preview-environment teardown.

The safest order is to remove or update DNS before deleting the third-party resource, or to ensure both are destroyed together through infrastructure as code. If the resource is removed first and DNS remains, a takeover window can appear.

For infrastructure managed through Terraform, Pulumi, AWS CDK, or similar tools, keep the DNS record and the service resource in the same lifecycle where possible. Separate manual DNS changes from UI-created vendor resources are a common source of drift.

• Decommissioning checklist — Use this checklist before shutting down any third-party service, cloud resource, or preview environment.

  # Before decommissioning
  # 1. Identify DNS records pointing to the service.
  # 2. Confirm whether each subdomain is still needed.
  # 3. Remove unused DNS records or repoint active ones.
  # 4. Wait for relevant TTLs where needed.
  # 5. Delete the third-party resource.
  # 6. Retest the subdomain externally.
  # 7. Update inventory and ownership records.

• Change-management guardrail — Require DNS impact review whenever a third-party service is deleted, a vendor contract ends, a CDN hostname changes, a cloud resource is destroyed, or a preview deployment system changes.

  # Pull request checklist example
  # - Does this change delete a hosted app, bucket, CDN service, Pages site, or vendor resource?
  # - Which DNS records point to it?
  # - Are those records removed or repointed in this same change?
  # - Who owns validation after deployment?

Real-world context

Public bug bounty reports show why subdomain takeover is taken seriously by mature security teams. One Uber HackerOne report described an authentication-impact scenario tied to a subdomain takeover and shared-cookie assumptions across subdomains. Uber resolved the issue and added additional protections for SSO cookies.

Microsoft’s Azure documentation also treats dangling DNS as a real platform risk. It describes risks such as content control, phishing, cookie harvesting, cross-site scripting, CSRF, and CORS bypass, and recommends removing dangling DNS entries and using domain verification or alias records where supported.

GitHub Pages documentation similarly recommends verifying custom domains to reduce the chance that another GitHub user can take over a custom domain after repository deletion, billing changes, or Pages configuration changes.

The practical lesson is not that one platform is uniquely unsafe. The lesson is that DNS records and platform resources must share a lifecycle. If DNS persists after ownership disappears, risk moves from theoretical to operational.

How to prioritize subdomain takeover findings

Not every candidate has the same risk. A stale subdomain on a dead marketing microsite is different from a stale subdomain trusted by SSO, OAuth, CORS, cookies, or customer-facing workflows.

Prioritize based on reachability, provider claimability, trust relationships, user traffic, authentication context, and whether the hostname appears in code, emails, mobile apps, OAuth redirect URIs, or customer documentation.

• Critical or high priority — The candidate affects login, SSO, OAuth redirects, API trust, session cookies, customer portals, payment flows, production apps, or high-traffic domains.

• Medium priority — The candidate affects public brand pages, docs, help centers, status pages, staging environments, or services with customer visibility but no direct authentication trust.

• Needs validation — A fingerprint suggests a missing resource, but provider behavior, account ownership, or claimability is not confirmed. Track separately until manually validated.

• Low priority — The subdomain no longer resolves, the DNS record has been removed, or the target resource is confirmed active and owned by your organization.

Where ExternalSight fits

ExternalSight fits the external attack surface monitoring layer for internet-facing domains. It does not replace your DNS provider, cloud provider, CI/CD controls, or internal vulnerability scanning.

ExternalSight includes subdomain discovery, certificate transparency checks, DNS scanning, passive DNS, subdomain takeover scanning, port and exposed service checks, cloud exposure signals, issue classification, remediation planning, historical comparison, alerting, PDF export, JSON export on supported plans, and attack-chain evaluation.

Monitoring is for verified domains on supported plans. That keeps continuous checks scoped to assets the organization controls.

Scanner coverage is tracked when external services, API keys, or modules are unavailable, so reports can show partial coverage instead of pretending every check succeeded.