Subdomain Takeover Prevention for SaaS Companies

In 2025, a security researcher claimed subdomains from 14 Fortune 500 companies in a single weekend. The technique: find DNS CNAME records pointing to deprovisioned cloud services, then register the target resource. Total cost: $0. Total effort: a few hours of DNS enumeration.

SaaS companies are the highest-risk category for subdomain takeovers. You spin up services constantly — staging environments, marketing landing pages, documentation portals, CI/CD endpoints — and deprovisioning rarely includes DNS cleanup.

One hijacked subdomain lets an attacker host phishing pages under your brand, steal cookies scoped to your parent domain, bypass CSP rules that trust *.yourdomain.com, and harvest credentials from customers who trust the URL.

How Subdomain Takeovers Work

The attack exploits a gap between your DNS configuration and your actual infrastructure.

Step 1: Your team creates docs.company.com with a CNAME record pointing to company.readthedocs.io.

Step 2: Months later, your team migrates documentation to a new platform and deletes the ReadTheDocs project. Nobody removes the DNS record.

Step 3: An attacker checks docs.company.com, sees it returns a “not found” error from ReadTheDocs. They register company on ReadTheDocs and now control what docs.company.com serves.

Step 4: The attacker hosts a phishing page at docs.company.com that looks like your login screen. Your customers trust the URL because it’s your domain.

The vulnerability exists whenever a DNS record (usually CNAME) points to an external service that no longer exists. This is called a “dangling DNS record.”

Vulnerable Pattern	Service	Risk Level
CNAME → deprovisioned S3 bucket	AWS S3	Critical — attacker creates bucket with same name
CNAME → deleted Heroku app	Heroku	Critical — attacker registers app name
CNAME → removed Azure resource	Azure	High — depends on resource type
CNAME → deleted GitHub Pages	GitHub	High — attacker forks/creates repo
CNAME → cancelled Shopify store	Shopify	Medium — requires Shopify signup
CNAME → removed Netlify/Vercel site	Netlify/Vercel	High — attacker claims domain
NS delegation → expired nameserver	Any	Critical — full DNS control

Why SaaS Companies Are Prime Targets

Three characteristics make SaaS companies particularly vulnerable:

Rapid infrastructure changes. Microservices architecture means dozens of subdomains: api-v1., staging., demo., beta., docs., status., admin.. Each one is a potential dangling record when the service behind it changes.

Third-party service dependency. SaaS companies use Heroku, Vercel, Netlify, AWS, GitHub Pages, ReadTheDocs, Zendesk, and dozens of other platforms that map via CNAME. Every cancelled subscription or migrated service leaves a potential dangling record.

Employee turnover. The engineer who set up staging-v2.company.com two years ago left the company. Nobody remembers what it points to. The DNS record persists because deleting unknown records feels risky.

A SaaSFort scan checks your domain’s DNS configuration as part of the 60-check security audit. Dangling CNAME records and orphaned subdomains surface as findings in the DNS security category.

The Business Impact

Subdomain takeovers are more than a technical vulnerability — they’re a business risk:

Phishing under your brand. Attackers host credential-harvesting pages on your subdomain. Your customers’ browsers show a valid URL with your domain name. SSL certificates can be issued for claimed subdomains via Let’s Encrypt (automated, no verification of ownership beyond DNS control).

Cookie theft. If your application sets cookies on .company.com (parent domain scope), any subdomain — including a hijacked one — can read those cookies. Session tokens, CSRF tokens, and authentication cookies become accessible to the attacker.

CSP bypass. Many Content Security Policies whitelist *.company.com. A hijacked subdomain becomes a trusted source for injected scripts, bypassing your XSS protections entirely.

Enterprise buyer impact. Security-conscious buyers scan your domain before engaging. A hijacked subdomain hosting malicious content triggers automatic alerts in tools like SecurityScorecard and BitSight. Your security grade drops, and the buyer moves on without telling you why.

NIS2 compliance risk. Under NIS2 Article 21(2)(e), organizations must implement vulnerability handling for their network and information systems. Dangling DNS records are a known vulnerability class. For German companies, §38 BSIG makes the Geschäftsführung personally liable for overseeing these measures.

5-Step Prevention Checklist

1. Inventory All Subdomains

You can’t protect what you don’t know exists. Start with a complete subdomain inventory.

Methods:

• Check your DNS zone file in Cloudflare, Route 53, or your DNS provider
• Run Certificate Transparency log searches via crt.sh — every SSL certificate ever issued for your domain is logged
• Use dig or nslookup to verify what each subdomain resolves to

Build a spreadsheet: subdomain, record type, target, owner, purpose, last verified date. This becomes your attack surface inventory.

2. Remove Dangling DNS Records

For each CNAME record, verify the target resource still exists:

• Visit the subdomain in a browser — does it return your expected content or an error page from the service provider?
• Check the external service — is the account/project/resource still active?
• If the resource is gone, delete the DNS record immediately

Priority: remove CNAME records pointing to deprovisioned S3 buckets, Heroku apps, and GitHub Pages first. These are the most commonly exploited.

3. Implement DNS Hygiene Processes

Prevention is a process, not a one-time cleanup:

• Deprovisioning checklist: Every service shutdown must include “remove DNS records” as a mandatory step
• Quarterly DNS audit: Review all DNS records against active services. Run a SaaSFort scan on your primary domain and each subdomain
• Ownership tags: Add TXT records or internal documentation linking each subdomain to a team and purpose
• Wildcard avoidance: Never use wildcard DNS records (*.company.com → your-server) — they mask orphaned subdomains

4. Monitor Continuously

Manual audits catch issues quarterly. Automated monitoring catches them daily.

• Certificate Transparency monitoring: Alert on any new certificates issued for your domain. Unexpected certificates may indicate a takeover in progress
• External scanning: SaaSFort’s CI/CD integration can verify DNS health on every deployment
• DNS change alerts: Configure your DNS provider to notify on record additions or modifications

5. Scope Cookies and CSP Correctly

Limit blast radius even if a subdomain is compromised:

• Set cookies on the specific subdomain (app.company.com) not the parent domain (.company.com)
• Restrict CSP to named subdomains instead of *.company.com. List each trusted subdomain explicitly
• Use __Host- cookie prefix for sensitive cookies — these can only be set on the exact domain, preventing subdomain override

These mitigations won’t prevent takeover, but they prevent an attacker from escalating a hijacked subdomain into a full account compromise.

Detection Methods

Method	What It Catches	Cost
SaaSFort scan	Dangling CNAMEs, DNS misconfigs, missing DMARC/SPF	€9/month
crt.sh CT log search	Unauthorized certificate issuance	Free
Manual DNS zone review	All record types including NS delegations	Free (time cost)
EASM platform	Continuous subdomain discovery + monitoring	€90-$25K/year
Bug bounty program	Active exploitation attempts	$500+ per valid finding

For most SaaS companies under 200 employees, the combination of quarterly manual review + continuous external scanning covers the risk adequately. Add an EASM platform when your subdomain count exceeds 50 and you can’t track them manually.

FAQ

How do I check if my subdomains are vulnerable right now?

Three steps: (1) List all subdomains via your DNS provider’s zone file or crt.sh. (2) Visit each CNAME-pointed subdomain — if you see a service provider’s “not found” page (e.g., “There isn’t a GitHub Pages site here”), it’s vulnerable. (3) Run a SaaSFort scan for automated DNS security checks including dangling record detection.

Can subdomain takeover lead to a data breach?

Yes. If cookies are scoped to the parent domain (.company.com), a hijacked subdomain can steal session tokens. Combined with CSP bypass, attackers can inject scripts that exfiltrate data from authenticated sessions. This qualifies as an NIS2-reportable incident under Article 23.

Does NIS2 require subdomain monitoring?

NIS2 Article 21(2)(e) requires vulnerability handling for network and information systems. Dangling DNS records are a recognized vulnerability class in OWASP and NIST frameworks. While NIS2 doesn’t name subdomain monitoring specifically, auditors expect documented processes for managing your external attack surface.

How often should I audit my subdomains?

Quarterly manual review at minimum. On every service deprovisioning ideally. If you use SaaSFort’s CI/CD webhook, DNS checks run on every deployment automatically. For comparison: Detectify and similar EASM tools offer continuous discovery, but at €90+/month.

What’s the difference between subdomain takeover and DNS hijacking?

Subdomain takeover exploits dangling CNAME records pointing to deprovisioned services — the attacker claims the target resource. DNS hijacking means the attacker gains control of your DNS records themselves (via registrar compromise, zone transfer, or NS delegation to expired nameservers). Both are DNS security issues, but hijacking is more severe and harder to execute.

---

Check your DNS security now. Free scan — includes dangling DNS detection, CNAME validation, DMARC/SPF/DKIM checks, and 54 additional security controls. A-F grade with NIS2 mapping. Under 60 seconds. Export as compliance PDF for your audit file. Download our free SaaS Security Playbook 2026 for the complete framework.