Origin IP exposure is the single most common reason a website protected by a CDN or scrubbing service still goes down under a DDoS attack. The defensive edge (Cloudflare, AWS CloudFront and Shield, Akamai, a scrubbing center) can only filter traffic that actually passes through it. If the origin server behind that edge is still reachable on its own public IP address, an attacker who discovers that address connects to it directly and the entire protective layer is bypassed in a single step. 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 before an adversary does.
This post covers what origin IP exposure is, the specific ways an origin address leaks, how to test for the exposure on your own infrastructure, and how to close it. The framing throughout is defensive: these are the techniques you run against yourself, under authorization, so that the door an attacker would use is already locked.
Why a CDN in front is not a wall
The mental model that causes the problem is treating a CDN as a perimeter. It is not a perimeter; it is a front door. A CDN or scrubbing service interposes itself between clients and the origin: DNS resolves to the provider's anycast IPs, traffic lands on the provider's edge, malicious traffic is filtered, and only cleaned traffic is forwarded to the origin server. As long as every visitor takes that path, the protection holds.
The catch is that the origin server still exists at a real IP address, and that address does not stop accepting connections just because a CDN was placed in front of it. The CDN changed where the name points; it did not change the fact that the server has a reachable network identity. If the origin's firewall accepts a connection from anywhere, then anyone who learns the origin IP can skip the front door entirely and knock directly on the server, sending attack traffic the CDN never sees and therefore never filters.
This is the gap. The defining question of origin IP exposure is simple to state and frequently never tested: can the origin be reached without going through the protective edge? If the answer is yes, the CDN is decorative under attack. The deeper mechanics of why this matters across attack types are covered in Understanding DDoS Attack Vectors; the concise definition lives at origin IP exposure.
How an origin IP leaks
Attackers do not guess origin addresses; they harvest them from public records and application behavior. Every vector below is a place a real IP commonly leaks, and every one of them 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 historical record does not disappear: passive-DNS databases (SecurityTrails, DNSDB, DNSDumpster and similar) archive what a name resolved to over time. A single lookup often returns the pre-CDN address, and 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 and through the CT APIs. Certificates routinely name internal hostnames, staging systems, and subdomains that were never meant to be public. Each of those names is a lead, and 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 gets put behind the CDN, but secondary records do not: mail., ftp., vpn., dev., staging., cpanel., direct., and origin. frequently resolve straight to the server or to an address in the same hosting block. Subdomain enumeration tools (subfinder, amass, dnsx) surface these in minutes, and one un-proxied subdomain on shared infrastructure can expose the whole origin.
Email and other DNS records. Mail is hard to proxy through a web CDN, so MX, SPF, and DMARC records often reference the real mail server, which is commonly the same host or the same IP range as the web origin. TXT verification records and old A/AAAA records left in the zone leak addresses the same way.
Application-layer leaks. The application itself frequently discloses its own origin. Origin IPs appear in JavaScript bundles and source maps, in API responses and webhook callbacks, in email headers (the Received: chain), in verbose error pages and stack traces, in HTTP response headers, and in server-status or monitoring endpoints left publicly reachable. A misconfigured redirect that bounces to the raw IP gives it away in one request.
Internet-wide scanners and fingerprinting. Services like Shodan, Censys, and ZoomEye continuously scan and index the public internet. An attacker filters those datasets for the target's TLS certificate (same CN/SAN), the same favicon hash, or distinctive response content, and finds every host serving that fingerprint, including the origin sitting outside the CDN. Favicon-hash matching is particularly effective: the icon served by the origin and by the CDN is identical, so a hash search across an internet-wide scan returns the unproxied host directly.
The pattern across all of these is that 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 is frequently skipped.
How to test for origin IP exposure
Testing for this exposure is a contained, low-risk exercise that maps onto exactly what an attacker would do, run under authorization against your own infrastructure. It has three phases.
Phase 1: enumerate candidate origins. Run the leak vectors above against your own domain. Pull passive-DNS history, search CT logs for every subdomain on the registrable domain, enumerate subdomains with subfinder/amass and resolve each, read the MX/SPF records, grep your own front-end bundles and API responses for IP literals, and check Shodan/Censys for hosts serving your certificate or favicon hash. The output is a list of candidate IP addresses 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 request returns your actual site (a 200 with your content, your application's cookies, your CSRF tokens), the candidate is a reachable origin and the protective edge has just been bypassed. A lower-level confirmation is a raw TCP connection to the origin's web ports from a source outside the CDN's published ranges; if the handshake completes, the port is open to the world.
Phase 3: confirm the expected rejection. A correctly configured origin produces the opposite result: the connection is refused, dropped, or times out, because the server's firewall only accepts traffic from the CDN's IP ranges. The finding you are looking for is binary and unambiguous. Either the origin answered a stranger (exposed, fail) or it did not (contained, pass). A defensible test records the exact candidate addresses tried, the response each returned, and the evidence (headers, body hash) proving whether the origin served content directly.
This is one of the highest-value tests in any engagement because it is both extremely common and completely invisible during normal operation. The site works perfectly through the CDN every day, so nothing signals that the back door is open until traffic arrives at it. 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, in rough order of strength:
Allowlist the edge at the origin firewall. The origin should accept inbound web traffic only from the CDN's published IP ranges and reject everything else. Every major provider publishes these ranges (Cloudflare at cloudflare.com/ips, AWS CloudFront via the com.amazonaws.global.cloudfront.origin-facing managed prefix list, and equivalents elsewhere). On AWS this is a security-group rule; the AWS-specific contour of this lockdown is covered in AWS DDoS testing. The constraint to remember in a hybrid stack, where one vendor's CDN fronts another vendor's origin, is to 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, where the CDN presents a client certificate the origin verifies) make the origin reject any connection that cannot prove it is the real edge, including connections that happen to come from within the provider's ranges.
Remove the public address entirely. The strongest option is to give the origin no internet-routable address at all. A private tunnel from the edge to the origin (Cloudflare Tunnel, a PrivateLink-style connection, a reverse connection from inside the network) means there is no origin IP to discover, because there is no public origin IP. You cannot knock on a door that does not exist.
Renumber after locking down, and keep it clean. If an origin IP has already leaked widely, lock down the firewall and then change the address, since the old one is burned and may sit in attack target lists. After that, the ongoing discipline is preventing fresh leaks: keep secondary subdomains and mail off the origin's address (or behind the edge too), strip IP literals from application output, and avoid certificates that name internal hosts.
Whichever fix is applied, the engagement is not complete until the bypass test is re-run and the direct connection now fails. Resilience is a measured property, not a configuration you assume held; the broader treatment of turning these checks into a posture score is in DDoS resilience testing.
FAQ
What is origin IP exposure?
Origin IP exposure is a configuration gap in which a server protected by a CDN or scrubbing service is still directly reachable on its own public IP address. Because the protective edge only filters traffic that passes through it, an attacker who discovers the origin IP can connect to the server directly, bypassing all CDN and DDoS protection in a single 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. If the origin server accepts connections from any source rather than only from the CDN's IP ranges, an attacker who finds the origin address connects to it directly and the CDN is never in the path. 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 application behavior: historical and passive DNS, Certificate Transparency logs, non-proxied subdomains (mail, dev, vpn), email DNS records (MX/SPF), IP literals leaked in JavaScript, API responses, error pages and HTTP headers, and internet-wide scanners (Shodan, Censys) matched by TLS certificate or favicon hash. None of it requires guessing.
How do you test for origin IP exposure?
Enumerate candidate origin IPs using the same public sources an attacker would, then attempt a direct connection to each that deliberately bypasses the CDN (for example, curl --resolve to force the hostname to the candidate address). If the origin serves your site directly, it is exposed. If the connection is rejected because the firewall only allows the CDN's ranges, it is contained. Then verify the fix with a re-test.
How do you fix an exposed origin?
Restrict the origin firewall to accept only the CDN's published IP ranges; optionally add authenticated origin pulls (mTLS) so the origin verifies the edge's identity; strongest of all, remove the origin's public IP entirely using a private tunnel. After locking down, renumber a widely-leaked IP, prevent future leaks from subdomains and application output, and re-run the bypass test to confirm direct access now fails.
A CDN is a front door, not a wall
The durable lesson of origin IP exposure is that adding protection in front of a server does nothing for the paths that go around it. A CDN, a scrubbing center, a WAF: each is a control on a specific route, and each is worth exactly as much as the guarantee that it is the only route. That guarantee is not automatic. It is a firewall rule, an authentication check, or a network design that has to be made on purpose and then verified.
The reason origin exposure persists across otherwise well-run environments is that 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, which is 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. A protective edge in front of a reachable origin is not protection; it is the appearance of it, and the difference between the two is a single connection that either gets refused or does not.