Your WAF is doing nothing if origin.yoursite.com answers the public directly
Put your site behind Cloudflare, or CloudFront, or Akamai, and you get a long list of protections at the edge: rate limiting, a managed rule set, bot mitigation, DDoS absorption. All of it lives at the CDN. None of it lives on your actual server. The whole arrangement works on one assumption, which is that every request reaches your origin through the CDN and there is no other door in.
There usually is another door. It's the hostname someone created so they could reach the box directly during setup, the one called origin.yoursite.com, or direct., or backend., or cpanel.. It points straight at the server's real IP, it's in public DNS, and it serves the same site. An attacker who finds it sends their traffic there instead, and every protection you bought at the edge is simply not in the path.
How an attacker finds the back door
They don't guess. The same public records that list your real subdomains, Certificate Transparency logs and passive DNS, list the origin hostname too if it ever got a certificate or was ever observed resolving. The naming gives it away. Ops teams reach for the same handful of words, so a quick filter for origin, direct, backend, real, or cpanel on a domain that's otherwise fronted by a CDN is a reliable way to find the bypass.
Once they have the origin's address, the attack is just sending requests to it. A credential-stuffing run that the edge would rate-limit goes straight through. A payload the managed rule set would block never meets the rule set. A volumetric flood that the CDN would absorb hits the server directly. The WAF didn't fail; it was never consulted.
Why this is a real finding and not "you use Cloudflare"
It would be easy to write a check that flags every non-CDN subdomain on a CDN-fronted site, and it would be wrong constantly. A marketing microsite, a status page, a mail host: plenty of subdomains legitimately sit off the CDN and aren't origin bypasses at all. So the finding requires more than a name. The apex has to genuinely be behind a CDN, the candidate hostname has to follow an origin-bypass naming convention, it has to be live and answering directly with no CDN in front of it, and, the part that makes it trustworthy, it has to serve the same application as your main site. That last test is the one that separates a real leaked origin from some unrelated box that happens to share your domain. The check confirms it by matching the TLS certificate or the page itself, so a bypass host serving a different app doesn't fire.
It also guards against wildcard DNS, where every imaginable subdomain resolves to the same place. Before flagging anything, the check probes a random throwaway hostname; if that answers with the same site too, the domain is a wildcard and an origin. hit proves nothing, so the finding stays silent. The result is a check that fires on a genuinely exposed origin and stays quiet on the everyday subdomains that look superficially similar.
What this finding claims, exactly
The honest scope here is "the edge is bypassable," not "your server is wide open." The origin might still enforce application auth, and a passive scan can't and won't test that. What it can say for certain is that the rate limiting, the managed rules, the bot and DDoS protection that only run at the CDN are all skippable, because the origin answers arbitrary clients directly. That's the medium-severity reality the finding is calibrated to: a defense-in-depth layer you're paying for isn't actually in the path for anyone who knows the back-door hostname.
Closing the door
The fix is to make the origin refuse anyone who isn't your CDN.
# origin.yoursite.com -> 203.0.113.7, public DNS # the server accepts requests from any client # -> the WAF/rate-limit/DDoS edge is skippable
Lock the origin's firewall to your CDN provider's published IP ranges so the server stops accepting connections from anywhere else. If your CDN supports it, turn on authenticated origin pulls or mutual TLS, which makes the origin reject any request that didn't come from the CDN even if the firewall is bypassed. Then deal with the hostname itself: remove the public DNS record for the bypass name, or move it somewhere that isn't internet-reachable. The goal is simple to state. Your server should only ever be reachable through the edge, and the origin hostname should not exist in public DNS for an attacker to find.
Reading it from outside
Finding a leaked origin is something an attacker does entirely from public data, and so does SurfaceCheckr. It reads the same Certificate Transparency and passive-DNS records, picks out the origin-convention hostnames on a domain that's actually CDN-fronted, and confirms a real bypass only when that host answers directly, off the CDN, serving the same site, proven by a matching certificate or page and screened against wildcard DNS. It never probes a raw origin IP and never sends an attack; it fetches hostnames the public records already volunteer and checks what they point at. For the wider map of what those public records expose about you, the staging and dev subdomains Certificate Transparency reveals is the companion read, and the full passive-reconnaissance picture is the frame around it.
Read next
- Your tech stack is public. Does that matter?What an attacker sees before they touch your site
- Your staging site is public, and Certificate Transparency just told everyone whereWhat an attacker sees before they touch your site
- Your /metrics endpoint is a live readout of your internals, and it's publicWhat an attacker sees before they touch your site
- What can someone learn about your site without hacking it?What an attacker sees before they touch your site
Find it before someone else does.
Paste your domain. The grade and issue count are free, and you'll see in a couple of minutes exactly what's reachable from outside.