Subdomain takeover

Why it matters

`the subdomain` still points at a third party, but the resource behind it is gone — a third party is serving its "nothing here" page. Anyone can now register that name on a third party and serve their own content from your subdomain, with a valid certificate for it. That is worse than a defaced page nobody visits. Cookies you scoped to the parent domain become readable by their page, a phishing form on your own domain looks exactly as legitimate as the real one, and any policy you wrote as "our domain and its subdomains" — CSP, CORS, cookie scope, SSO redirects — now trusts content you do not control.

How ShipReady detects it

Dangling CNAMEs on hostnames the scanned site itself references. SITE-scoped: the candidate set spans the whole crawl, and each hostname must be resolved once rather than once per page that mentions it.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

The DNS record for the subdomain still points at your provider (CNAME to the service it points at), but the resource behind it has been deleted — your provider is serving its "nothing here" page. Until you remove or repoint that record, anyone can register that name on your provider and serve their own content from the subdomain, with a valid certificate for it.

Fix it in this order. FIRST, remove the dangling DNS record: open your DNS provider, find the CNAME for the subdomain, and delete it — that closes the hole immediately and is the only step that must happen now. If the subdomain is still meant to be in use, re-create the resource on your provider FIRST and only then point the CNAME back at it, so the name is never claimable in between.

Then check the blast radius. While the record was live, any cookie scoped to the parent domain was readable from that subdomain, so rotate session secrets if you cannot rule out that someone claimed it. Review anything that trusts your domain by wildcard — CSP frame-ancestors and script-src, CORS allow-lists, OAuth redirect URIs, SSO callback URLs — and prefer exact hostnames over *.yourdomain.com where you can. Finally, audit the rest of your zone for the same pattern: a released service leaves a working DNS record behind every time, so one dangling record usually means the cleanup step is missing from a process rather than from a single deploy.

Frequently asked questions

What does "Subdomain takeover" mean?

`the subdomain` still points at a third party, but the resource behind it is gone — a third party is serving its "nothing here" page.

How serious is it?

ShipReady rates this critical. Fix before launch. On its own, this is enough to compromise the application.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• Anthropic API Key Exposedcritical
• Firebase Realtime Database is publicly readablecritical
• Firebase Storage bucket is publicly listablecritical
• Supabase Row Level Security is not enabledcritical
• A redirect parameter sends visitors to any URL it is givenhigh
• A response sets a session cookie and allows shared cachinghigh