Origin Exposure Check
A site behind a CDN/WAF like Cloudflare only stays protected while its real origin server can't be reached except through the CDN. If the origin IP leaks, an attacker connects straight to it and skips the WAF and DDoS protection entirely. This defensive check looks at a domain you control: it works out whether a CDN sits in front, then harvests candidate origin IPs from the domain's own public data — Certificate-Transparency subdomains, A/AAAA records, MX hosts and SPF/TXT entries — and proves whether any leaked IP actually serves the site when contacted directly. It uses only public data and read-only GETs of the domain's own hosts; no scanning of unrelated hosts, no attack traffic.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- CDN/WAF posture — whether a CDN (Cloudflare and similar) fronts the apex, detected by published Cloudflare IP ranges, the cf-ray header, and the Server header
- Certificate-Transparency subdomains — non-CDN IPs behind common hosts like mail, cpanel, dev, staging that likely share the origin box (ORIGIN_LEAK_SUBDOMAIN)
- MX hosts — mail servers resolving to a non-CDN IP; if mail runs on the web origin, this leaks it (ORIGIN_LEAK_MX)
- SPF / TXT entries — ip4:/ip6:/a:/mx: mechanisms that name a non-CDN IP which may be your origin (ORIGIN_LEAK_SPF)
- Bypass validation — connecting directly to each leaked IP with the apex Host header and comparing the response to the through-CDN site, to confirm whether it really serves the origin (ORIGIN_EXPOSED)
- Exposure inventory — the full classified graph of every related host: its CNAME chain, final IPs, ASN/provider, whether it sits in your owned footprint, whether it's a CDN edge, its live status/server banner/title, and a confidence score with the exact signals that decided it
- Each host is sorted into one of seven categories: Confirmed origin (a proven CDN bypass), Protected origin (an owned IP answering the apex Host with a 401/403/5xx or WAF banner), Related web app, Related service (an admin panel or non-HTTP service by banner — SFTP, Grafana, phpMyAdmin, SSH…), Mail sender (an IP seen only via SPF/MX), Third-party / CDN (a Cloudflare or SaaS edge), and Stale / gone (a host that no longer resolves)
How to read the result
- OK — not behind a CDN: no CDN/WAF was detected in front of the domain, so its web IPs are reachable directly by design and there is no CDN to bypass.
- OK — behind CDN, no leak: a CDN fronts the site and no origin-IP leak was found in its public data; keep the origin firewall restricted to the CDN's ranges.
- Fail — origin exposure CONFIRMED: one or more IPs serve the site when contacted directly, bypassing the CDN — the WAF/DDoS protection can be skipped by connecting straight to the origin. These are the highest-priority IPs to firewall off.
- Warn — leaks found, none confirmed: non-CDN IPs leak from the domain's own subdomains/MX/SPF but none was proven to be the live origin; review each and lock the origin firewall down to CDN ranges.
- Candidate rows are sorted worst-first: confirmed exposed origins, then other non-CDN leaks, then Cloudflare addresses, each labelled with where it leaked from (subdomain, MX, SPF).
- Remember leaked IPs persist: historical DNS and Certificate-Transparency records keep an old origin IP forever, so rotating the IP after locking DNS down is part of the fix.
- The exposure inventory groups every related host by category, worst-first: 'Confirmed origin' (red — a proven bypass to firewall off immediately), 'Protected origin' and 'Related service' (amber — owned infrastructure to review), then 'Related web app', 'Mail sender', 'Third-party / CDN' and 'Stale / gone' as context. Expand any host to see its CNAME chain, IPs, ASN/provider, whether it's in your owned footprint, the live banner, and the confidence score with the signals (the 'Why') behind the category.
Frequently asked questions
How can someone bypass Cloudflare or another CDN?
A CDN/WAF only protects traffic that goes through it. If the real origin server's IP is discoverable — via a subdomain that isn't proxied, an MX or cPanel host on the same box, an SPF record listing the IP, or old Certificate-Transparency entries — an attacker can connect to that IP directly with the site's Host header and reach the application without the WAF, rate-limiting or DDoS protection. This check finds those leaks the same way an attacker would, so you can close them.
Is this an attack tool? Can I run it against any domain?
It's a defensive self-assessment. It uses only public data about the named domain (Certificate Transparency, DNS, SPF) and read-only GETs of that domain's own candidate hosts — no brute force, no open-port checkning, no attack traffic, and nothing aimed at unrelated hosts. Run it on domains you own or are authorised to assess, to audit whether your origin is exposed.
My origin IP is leaking — how do I lock it down?
Restrict the origin firewall to the CDN's published IP ranges so the origin only accepts traffic from the CDN; enable Authenticated Origin Pulls (mTLS) so even a leaked IP can't be used without the CDN's client certificate; rotate the origin's public IP after DNS is locked down so historical records stop working; and keep mail, control panels and dev/staging hosts off the protected web box (Cloudflare Tunnel removes the public origin IP entirely).
Why do subdomains, MX and SPF records leak the origin?
Records that can't be proxied through the CDN expose a real IP. A 'mail' or 'cpanel' or 'dev' subdomain often points straight at the same server as the website; MX records must point at a reachable mail host; and SPF/TXT records frequently list the sending server's IP (ip4:/ip6:). If any of those is the same machine as your web origin, its address is public even though the website itself is proxied.
What does a 'confirmed' origin mean versus a 'leak'?
A leak is a non-CDN IP harvested from your public records that might be the origin. The check then connects to that IP directly using the apex Host header and compares the response (status, title, body) to the site served through the CDN. If they match, it's labelled a confirmed exposed origin — proof that the WAF can actually be bypassed via that IP — rather than just a suspicious address to review.
Does it work for CDNs other than Cloudflare?
It detects CDN posture from Cloudflare IP ranges, the cf-ray header and the Server header, so Cloudflare is identified by name and its published ranges drive the remediation advice. Sites behind other CDNs are detected via their Server header where present; the leak-harvesting and direct-bypass validation work the same way regardless of provider.