A CDN only protects the traffic that flows through it.
If your origin server still answers on its own public IP, an attacker who finds that IP connects straight to it. Every layer of DDoS and WAF protection is bypassed in a single step.
That gap is origin IP exposure. It is the most common reason a site behind a CDN still goes down under attack.
It is a configuration gap, not a product weakness. And it is exactly the class of failure a thorough DDoS test is built to find first.
The framing here is defensive throughout. These are the checks you run against your own infrastructure, under authorization, so the door an attacker would use is already locked.
Why a CDN in front is not enough
The mistake is treating a CDN as a perimeter. It is not a perimeter. It is a front door.
A CDN sits between clients and your origin. DNS points at the provider's anycast IPs, traffic lands on its edge, the bad traffic is filtered, and only clean traffic is forwarded on.
As long as every visitor takes that path, the protection holds.
But the origin server still exists at a real IP address. Putting a CDN in front did not change that. It changed where the name points, not the fact that the server still answers the network.
So if the origin's firewall accepts a connection from anywhere, anyone who learns its IP can skip the front door entirely.
They knock directly on the server, sending attack traffic the CDN never sees and never filters.
The defining question, and one that is rarely tested: can the origin be reached without going through the edge? If yes, the CDN is decorative under attack.
The chart below is what "decorative under attack" looks like. It comes from a small simulation of a volumetric flood against the same workload, once with the origin behind the CDN and once with the origin exposed.
The deeper mechanics across attack types are in Understanding DDoS Attack Vectors. The short definition lives at origin IP exposure. And once the origin is hidden, how much of a flood the edge actually absorbs comes down to what it caches, which is the subject of CDN cache and DDoS.
How an origin IP leaks
Attackers do not guess origin addresses. They harvest them from public records and from the application's own behavior.
Every vector below is a place a real IP commonly leaks. Every one is something you can audit on your own estate.
Historical and passive DNS
Before the CDN was deployed, the domain almost certainly pointed straight at the origin.
That record does not disappear. Passive-DNS databases (SecurityTrails, DNSDB, DNSDumpster) archive what a name resolved to over time. Origins are rarely renumbered after the cutover, so the old answer is usually still live.
Certificate Transparency logs
Every publicly trusted TLS certificate is logged to public, append-only CT logs, queryable at crt.sh.
Certificates routinely name internal hostnames, staging systems, and subdomains that were never meant to be public. Any one that resolves outside the CDN points back toward the origin.
Non-proxied subdomains
This is the most common leak in practice. The primary hostname goes behind the CDN, but secondary records do not.
mail., ftp., vpn., dev., cpanel., direct. often resolve straight to the server or to an address in the same block.
Tools like subfinder and amass surface these in minutes. One un-proxied subdomain on shared infrastructure can expose the whole origin.
Email and DNS records
Mail is hard to proxy through a web CDN. So MX, SPF, and DMARC records often reference the real mail server.
That host is commonly the same machine, or the same IP range, as the web origin.
Application-layer leaks
The application frequently discloses its own origin.
IP literals show up in JavaScript bundles and source maps, in API responses and webhooks, in email headers, in verbose error pages, and in server-status endpoints left public.
A single misconfigured redirect to the raw IP gives it away in one request.
Internet-wide scanners
Shodan, Censys, and ZoomEye continuously index the public internet.
An attacker filters those datasets for your TLS certificate or your favicon hash, and finds every host serving that fingerprint, including the origin sitting outside the CDN.
The pattern across all of these: the origin is rarely hidden. It is merely not pointed to by the primary name. Hiding a name is easy. Making the address unreachable is the part that gets skipped.
How to test for origin IP exposure
Testing for this is a contained, low-risk exercise, and it is one of the first checks in any professional DDoS testing engagement. It maps onto exactly what an attacker would do, run under authorization against your own domain.
Three phases.
Phase 1: enumerate candidate origins
Run the leak vectors above against your own domain.
Pull passive-DNS history, search CT logs, enumerate and resolve subdomains, read the MX/SPF records, grep your own bundles for IP literals, and check Shodan/Censys for your fingerprint.
The output is a list of candidate IPs that might be the origin.
Phase 2: attempt the bypass
For each candidate IP, try to reach the site directly, deliberately skipping DNS and the CDN.
The canonical test forces the hostname to resolve to the candidate address:
curl -sv --resolve www.example.com:443:203.0.113.10 https://www.example.com/ -o /dev/null
If that returns your actual site, the candidate is a reachable origin, and the edge has just been bypassed.
Phase 3: confirm the rejection
A correctly configured origin does the opposite. The connection is refused, dropped, or times out, because the firewall only accepts the CDN's ranges.
The finding is binary. Either the origin answered a stranger (exposed), or it did not (contained).
Or run it automatically
We packaged this exact check into a small, open-source tool written in Rust: origin-exposure-check.
Point it at a domain you own. It pulls the published CDN ranges, enumerates candidates from common subdomains and CT logs, and makes a direct request to each non-edge IP:
cargo run --release -- example.com
It prints EXPOSED for any IP that serves your site past the CDN, and CONTAINED when the origin refuses. No attack traffic, authorized self-testing only.
Keeping the whole exercise inside a safe boundary is the subject of running a DDoS test without disrupting production.
Closing the exposure
Finding an exposed origin is only useful if the fix is verified by a re-test. The remediations, strongest last.
Allowlist the edge
The origin should accept inbound web traffic only from the CDN's published ranges, and reject everything else.
Every provider publishes these (Cloudflare at cloudflare.com/ips, AWS via the com.amazonaws.global.cloudfront.origin-facing prefix list). The AWS contour is covered in AWS DDoS testing.
In a hybrid stack, allowlist the CDN's ranges, not the host cloud's, a distinction worked through in AWS Shield vs Cloudflare.
Authenticate the edge
IP allowlists are strong, but the published ranges are large and shared.
Authenticated origin pulls (mutual TLS) make the origin reject any connection that cannot prove it is the real edge, even from within the provider's ranges.
Remove the public address
The strongest option is to give the origin no internet-routable address at all.
A private tunnel from the edge (Cloudflare Tunnel, a PrivateLink-style link) means there is no origin IP to discover. You cannot knock on a door that does not exist. Confirming that lock holds on a Cloudflare-fronted origin is the central check in Cloudflare DDoS testing.
Renumber, and keep it clean
If an IP has already leaked widely, lock down the firewall and then change the address, since the old one is burned.
After that, prevent fresh leaks: keep subdomains and mail off the origin's address, strip IP literals from output, and avoid certificates that name internal hosts.
The engagement is not complete until the bypass test is re-run and the direct connection now fails. Turning these checks into a posture score is covered in DDoS resilience testing.
FAQ
What is origin IP exposure?
A configuration gap where a server behind a CDN is still directly reachable on its own public IP. Because the edge only filters traffic that passes through it, an attacker who finds the origin IP bypasses all CDN and DDoS protection in one step.
Can you really bypass Cloudflare or a CDN?
Yes, when the origin is reachable directly. A CDN protects the path through it, not the server's underlying network identity. The defense is to make the origin reject anything that did not come through the edge.
How do attackers find the origin IP behind a CDN?
Through public records and app behavior: passive DNS, Certificate Transparency logs, non-proxied subdomains, MX/SPF records, IP literals in JavaScript, and internet-wide scanners matched by TLS cert or favicon hash. None of it requires guessing.
How do you fix an exposed origin?
Restrict the origin firewall to the CDN's published ranges; add authenticated origin pulls; strongest of all, remove the public IP with a private tunnel. Then re-run the bypass test to confirm direct access now fails.
The test is the only proof
Origin exposure persists in well-run environments because everything looks correct from the outside.
The name resolves to the CDN. The site loads through the CDN. The dashboards are green.
None of that observes the one thing that matters under attack: whether the server will still answer a stranger who knocks directly.
The only way to know is to be the stranger, knock, and see what happens.