I put Cloudflare in front of my site, then found my origin one DNS record away from undoing it

You move your site behind Cloudflare (or CloudFront, or any CDN/WAF), watch the dashboard light up green, and feel safe. The edge will soak up the floods now. Right?

Mostly. But there is a quiet failure mode that undoes the whole thing in one step, and almost nobody tests for it: origin IP exposure.

The problem in one sentence

A CDN only filters the traffic that actually passes through it. If your origin server still answers on its own public IP, an attacker who learns that IP just connects straight to it, and every layer of DDoS and WAF protection you are paying for is bypassed.

The edge is protecting a secret (your origin IP), not a wall. And secrets leak.

How the secret leaks

You do not need to breach anything to find an origin. The data is usually already public:

• 
  Certificate Transparency logs. Every TLS certificate ever issued is logged publicly. Search crt.sh for a domain and you get a tidy list of its subdomains, including the dev, staging, and mail hosts nobody remembered to put behind the CDN.


• 
  Boring subdomains. mail., smtp., vpn., cpanel. and friends are hard to proxy through a web CDN, so they frequently resolve straight to the origin, on the same IP as the "protected" site.


• 
  DNS history. The A record from before you switched to the CDN is often still sitting in historical DNS datasets.

Find one of those, confirm the IP serves the real site, and the CDN is now optional.

So I built a small tool to check my own

I wanted a one-command answer to "is my origin reachable past my CDN, right now?" So I wrote origin-exposure-check in Rust. It does exactly the discovery an attacker would, against a domain you own, so you find the leak first.

It is deliberately boring on the network: a few DNS lookups, one crt.sh query, and a handful of normal GET requests. No flooding, no attacks. Single binary, no config.

Here is the whole flow:

1. Pull the published edge ranges (Cloudflare, CloudFront) so we can exclude the legitimate edge IPs.


2. Fetch a baseline of the site through the CDN, and fingerprint the response.


3. Enumerate candidate hosts from common subdomains + Certificate Transparency (crt.sh).


4. For every candidate IP that is not an edge IP and not the front door, make a direct request to that IP while presenting the real hostname, deliberately bypassing DNS and the CDN.


5. If the origin answers with your site, that is EXPOSED. If it refuses, CONTAINED.

The interesting part is step 4. To test reachability you force a TLS connection to a specific IP but set the SNI/Host to the real domain, so the origin thinks it is a normal request:

// Force TLS to a specific IP while presenting the real hostname (SNI),

// i.e. deliberately bypass DNS/CDN. Cert validity is ignored on purpose:

// we are probing reachability, not trust.

let connector = native_tls::TlsConnector::builder()

    .danger_accept_invalid_certs(true)

    .danger_accept_invalid_hostnames(true)

    .build()?;



let stream = TcpStream::connect((ip, 443))?;

let mut tls = connector.connect(domain, stream)?; // domain = SNI, ip = where we actually connect

tls.write_all(

    format!("GET / HTTP/1.1\r\nHost: {domain}\r\nConnection: close\r\n\r\n").as_bytes(),

)?;

If the bytes that come back match the baseline fingerprint, that IP is serving your real site directly. Caught.

It also handles the obvious false positive: if every candidate IP returns byte-identical content, you are on an anycast host platform (Vercel, Netlify, Cloudflare Pages) where the host is the edge, there is no separate origin to expose, and it says so instead of crying wolf.

Running it

cargo run --release -- example.com

# or build once, then:

./target/release/origin-exposure-check example.com

A CONTAINED run looks calm. An EXPOSED run hands you the IPs and the fix:

Fix: restrict the origin firewall to the CDN's published ranges (or use a private tunnel so there is no public origin IP), then re-run this check.

That is the actual remediation: your origin should only accept connections from your CDN's IP ranges, or have no public inbound listener at all (a tunnel). Allow the world, and the CDN is decoration.

One important rule

Run it only against domains and infrastructure you own or are explicitly authorized to test. It is a self-audit, and it only consumes already-public data, but point it at your own stuff.

Code + the deeper write-up

• Tool (MIT, Rust):
  

If you run it on your own site and get a surprising EXPOSED, I would genuinely like to hear how the IP leaked. That is usually the interesting part.

Written while building defensive tooling at BlackNeuron.