Behind Cloudflare but still exposed: finding the origin IP

Putting a site behind Cloudflare, Fastly, Akamai or another CDN buys you a WAF, rate limiting, bot management and DDoS absorption. But all of that lives on the CDN's edge, in front of your server, and only protects traffic that actually passes through the edge. If an attacker learns the real IP address of the machine behind the CDN — the origin — they can connect straight to it and none of that protection is in the path anymore.

The WAF only guards the door everyone uses

Public DNS points your hostname at the CDN's edge; the edge inspects each request, applies your WAF rules and rate limits, and forwards clean traffic to the origin over a private path. The security model has one hard assumption baked in: the origin is reachable only through the edge. Break that assumption and the whole thing degrades to decoration.

When the origin's IP is reachable from the internet, an attacker who knows it can send requests straight to https://203.0.113.10/ with your hostname in the Host header. Those requests never touch the edge, so the WAF never sees them, the rate limiter never counts them, and the DDoS shield never absorbs them. Application-layer attacks and floods alike land on the raw server. The padlock is intact; the wall around it has a second gate nobody is watching.

How origins leak

Origins rarely leak because someone attacks the CDN. They leak because the IP was written down somewhere public — usually before the CDN was ever put in front, and usually in a record nobody thinks of as sensitive. Finding it is passive reconnaissance against public data, which is exactly why it is worth auditing your own estate the same way.

Certificate Transparency logs

Every publicly trusted TLS certificate is logged to append-only Certificate Transparency (CT) logs, and those logs are fully searchable. If your origin ever presented a certificate directly — a staging box, a monitoring endpoint, or the bare server before you moved behind the CDN — the hostname is now permanently public. CT logs also enumerate subdomains you may have forgotten, each a fresh candidate to resolve. You cannot un-log a certificate; the exposure is durable.

Historical and stray DNS records

DNS has a long memory. Passive-DNS databases retain the answers a name returned in the past, so an A record that pointed at the origin before you enabled proxying can persist there long after you changed it. Even in the live zone, records drift out of sync: an apex proxied through the CDN, but a www, cpanel, or old record still pointing at the bare server.

Subdomains that skip the CDN

Not everything is comfortable behind a CDN, so operators quietly route some names around it. The usual suspects give themselves away by name:

• mail., smtp., mx. — mail almost never runs through an HTTP CDN.
• ftp., ssh., vpn. — non-HTTP services the CDN cannot proxy.
• dev., staging., test. — environments set up before anyone thought about proxying.
• direct., direct-connect., origin. — names created specifically to reach the server without the CDN, which is precisely the address an attacker wants.

If any of those resolves to the same machine that serves your proxied traffic, the CDN-fronted hostname and the exposed one share an origin, and the protection is moot.

Email records: SPF and MX

Mail infrastructure routinely publishes IP addresses in the clear. An SPF record enumerates the hosts allowed to send mail for the domain, sometimes including the application server itself if the app sends transactional email:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

That ip4: token is a plaintext pointer to a server, and if it is the same host that serves the site, it is the origin. MX records leak the mail host's name (and thus its IP) the same way. Neither is a misconfiguration on its own — but each is a public breadcrumb.

Response headers and same-IP neighbours

A misconfigured origin can also announce itself: verbose Server banners, framework debug pages, or a Location redirect that hands back the server's own IP. And an origin rarely lives alone — other services on the same IP tie that address back to you and confirm a candidate found elsewhere.

Why a single leaked IP undoes the whole setup

It only takes one. The CDN can be flawlessly configured on every proxied hostname, but a single forgotten dev. record, old certificate in a CT log, or ip4: token in your SPF is enough — an attacker connects to the origin and works entirely outside your defences. It is the same "weakest host wins" pattern behind subdomain takeover: one stale or careless record quietly becomes the way in.

Defending the origin

The fix is to make the origin genuinely unreachable except through the CDN, and to stop leaking its address in the first place. These reinforce each other; do as many as apply.

• Firewall the origin to the CDN's IP ranges. Every major CDN publishes the address ranges its edge connects from. Configure the origin's host firewall or cloud security group to accept inbound web traffic only from those ranges, so a direct hit to the origin IP is refused at the network layer even when the attacker knows the address. Keep the ranges updated — CDNs do change them.
• Prefer an authenticated tunnel. Where the CDN offers an outbound tunnel from the origin, so the server holds no public inbound listener at all, that is stronger still — there is no public port to find. Pair either approach with authenticated origin pull (mTLS): configure the origin to require a client certificate that only your CDN presents, and refuse any connection that can't offer it. A plain server certificate only encrypts the edge-to-origin hop — it does nothing to stop a direct connection — whereas requiring the CDN's client certificate turns "knowing the IP" into "still gets no response."
• Don't issue certificates that reveal the origin. Because CT logging is permanent, avoid presenting publicly trusted certificates directly from the origin. Let the CDN terminate TLS at the edge and use a private or CDN-issued origin certificate for the edge-to-origin hop, so the server's own hostname never appears in a public log.
• Keep non-proxied records off the origin IP. Audit every DNS record, not just the apex and www. Any A/AAAA record that must stay unproxied should live on a different IP than the one serving your proxied traffic, and records you no longer use should be removed.
• Don't reuse the origin IP across proxied and non-proxied names. The moment your mail host, staging box, or SPF-listed sender shares an address with the application origin, every one of those public records points an attacker at the machine the CDN is supposed to hide. Separate the roles onto separate addresses. And if the origin was ever internet-facing before you moved behind the CDN, assign it a fresh IP — its old address is already in passive-DNS history and possibly CT logs.

How Cyber Report checks this

When Cyber Report detects that a site is fronted by a CDN it can classify (currently Cloudflare and Fastly), it takes every IP already gathered for the domain — the apex A/AAAA records, MX hosts, ip4:/ip6: addresses parsed out of SPF, and the addresses of subdomains discovered via Certificate Transparency logs — and checks each one against the CDN's published edge ranges. Any address that falls outside those ranges is flagged as a potential origin leak (high severity), with every IP and its source listed so you can tell a real exposure from a legitimate off-CDN host like a mail server. It is purely derivative and non-intrusive — no packets to your origin — and runs alongside our wider DNS, WAF-fingerprint, subdomain and reachable-port checks. A leaked address that also serves over deprecated TLS, or exposes a database port directly, only compounds the exposure.

See what we scan, or run a scan on your own domain to see where you stand.