The Hidden DDoS Vulnerability in Your Infrastructure
How attackers bypass your CDN and why traditional defenses fail
Executive Summary
Most organizations believe their CDN provides complete DDoS protection. They're wrong. Academic research from Stanford and UC San Diego shows that a significant majority of CDN-protected websites have at least one exploitable path to their origin server. This article explains the attack vectors, why they exist, and how to eliminate them.
The False Sense of Security
You've deployed Cloudflare. Or AWS CloudFront. Or Akamai. Your security team reports "DDoS protection: enabled." Your CISO signs off. Everyone sleeps well.
Then you get hit with a 50 Gbps attack that takes down your production servers for 6 hours.
What happened?
The attacker didn't go through your CDN. They went around it.
The 5 Most Common CDN Bypass Techniques
1. Historical DNS Records
Every DNS change leaves traces. Services like SecurityTrails, DNSHistory, and Shodan archive historical DNS records indefinitely.
The attack:
1. Look up historical A records for target.com
2. Find: 2019-03-15 -> 203.0.113.50 (origin IP)
3. Attack 203.0.113.50 directly
4. CDN never sees the traffic
Why it works: When companies migrate to CDN, they change their DNS but forget that the old IP is still active and publicly known.
2. Subdomain Enumeration
Your www.company.com is behind Cloudflare. But what about:
staging.company.comapi-internal.company.comdev.company.comjenkins.company.com
The attack:
1. Enumerate all subdomains (cert transparency, brute force)
2. Find: staging.company.com -> 203.0.113.51
3. Staging is same /24 as production
4. Attack staging, saturate the upstream link
5. Production goes down as collateral
3. Email Headers and SPF Records
Your email infrastructure often reveals your origin.
1. Send email to [email protected]
2. Receive auto-reply or bounce
3. Check email headers: Received: from mail.company.com (203.0.113.52)
4. Check SPF: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all
5. Now we know the origin IP range
4. SSL Certificate Scanning
When your origin server accepts HTTPS, it presents a certificate. Attackers scan the entire IPv4 space looking for your certificate.
1. Use Censys/Shodan to search: ssl.cert.subject.CN:"company.com"
2. Find: Certificate for company.com at 203.0.113.50
3. This IP doesn't match CDN ranges
4. Attack directly
5. Leaked Configuration Files
Developers accidentally expose configuration that reveals infrastructure:
.envfiles withORIGIN_IP=203.0.113.50docker-compose.ymlwith internal IPs- GitHub repos with infrastructure code
- Error pages that show internal hostnames
The Attack Economics
| Protection Level | Attack Cost | Success Rate |
|---|---|---|
| No CDN | $50/hour | 95% |
| CDN (misconfigured) | $200/hour | 73% |
| CDN (properly configured) | $2,000/hour | 15% |
| CDN + Origin lockdown + Monitoring | $10,000+/hour | 3% |
Key insight: Proper configuration is more important than which CDN you choose.
Self-Assessment Checklist
- All historical DNS records point to CDN or are null-routed
- Origin firewall allows ONLY CDN IP ranges
- All subdomains are inventoried and protected
- Email infrastructure is isolated from web servers
- Origin uses CDN-provided certificates
- No .env files accessible via web
- GitHub repos scanned for infrastructure leaks
- Direct origin access attempts are logged and alerted
Ready to Find Your Blind Spots?
Use our free self-check CLI tool to scan your domains, or contact us for a comprehensive assessment.
Start Your Free AssessmentConclusion
CDN protection is necessary but not sufficient. The gap between "protected" and "actually protected" is where attackers operate. Close that gap by:
- Knowing your entire attack surface (not just the main domain)
- Locking down your origin (firewall + network isolation)
- Monitoring continuously (new subdomains, DNS changes, certificate issuance)
- Testing regularly (controlled simulations, not just theory)
The attackers are automated. Your defenses should be too.