← All articles

Why Cloudflare Proxying Alone Isn't Enough

Alexander Norman
cloudflarewaf-bypassorigin-securityzero-trust

Many organizations put Cloudflare in front of their web applications and assume they're protected. WAF rules, DDoS mitigation, bot management — all handled by Cloudflare's edge network.

But there's a fundamental problem with the most common setup: if your origin server accepts traffic from any Cloudflare IP, every Cloudflare customer can reach it directly.

The Problem: Shared IP Ranges

When you proxy your domain through Cloudflare, traffic flows like this:

User → Cloudflare Edge → Your Origin Server

To "protect" the origin, many teams add firewall rules:

Allow inbound HTTP/HTTPS from Cloudflare IP ranges

This seems logical. Only Cloudflare can reach your origin. Except...

Cloudflare's IP ranges are shared across all ~30 million domains on their network. Any Cloudflare customer can route traffic through those same IPs using:

  • Cloudflare Workers — deploy a Worker that fetches your origin with a custom Host header
  • Proxied DNS — create an A record pointing to your origin IP in their own CF zone
  • Cloudflare Tunnel — configure a tunnel ingress rule with httpHostHeader override

All three methods cause traffic to arrive at your origin from Cloudflare's IP ranges, bypassing your firewall rules completely.

Finding the Origin IP

The first step for an attacker is discovering your origin IP. Despite Cloudflare proxying, this is often trivial:

Non-proxied subdomains

mail.example.com    → 203.0.113.10  (Oderland, direct)
www.example.com     → 104.16.x.x   (Cloudflare, proxied)

Mail servers, FTP, cPanel, staging environments — these commonly point directly to the origin.

Certificate Transparency logs

Every TLS certificate issued is logged publicly. Searching crt.sh reveals subdomains that may have existed before Cloudflare was added, or internal services with their own certificates.

Historical DNS

Services like SecurityTrails, RapidDNS, and Shodan maintain historical DNS records. Even if you moved behind Cloudflare years ago, the old A record pointing to your origin is preserved.

Shodan / Censys

Search engines for internet-connected devices index your origin's IP, ports, and TLS certificates — often revealing the exact hostname served.

The Bypass in Practice

Once an attacker has the origin IP, they can:

  1. Connect directly — if the origin accepts traffic from any source (no firewall at all)
  2. Route through Cloudflare — if the origin only accepts CF IPs, use a Worker/proxied DNS/tunnel

The second case is the interesting one, and it's worth being precise about what actually gets bypassed:

  • Bypassed: origin NSG / firewall allow-lists that trust CF IP ranges. The request still exits CF's network, just from a different customer's zone, so the origin sees a legitimate CF source IP.
  • Still enforced (in most cases): the target zone's WAF rules, rate limiting, bot management, and Access policies. These live at the edge of the target's zone, not at the origin. If the attacker's Worker sets Host: target.example.com, the request is routed back through the target's zone and its WAF evaluates the payload.

In our own authorized testing we confirmed this: Worker-routed LFI payloads were still blocked with 403 by the target zone's WAF, and Access-protected routes still redirected to the IdP login flow.

The real bypass value is narrower but still serious: it defeats the "Cloudflare IPs only" firewall rule, which is often the only layer between attacker and origin. Once the IP allow-list is beaten, attackers can:

  • Enumerate the origin directly without hitting your WAF at all (via Mode 3, if NSG is weak).
  • Probe for origin services that aren't fronted by CF (admin panels, staging, APIs on other ports).
  • Exploit misconfigurations where the target zone's WAF rules are weaker than assumed — e.g., a permissive path rule at the origin that blocks at edge but not when approached with a different SNI.

The Fix: Cloudflare Tunnel (cloudflared)

The correct architecture uses Cloudflare Tunnel (formerly Argo Tunnel):

User → Cloudflare Edge → cloudflared daemon → Your Origin

Key difference: the origin never listens on a public IP. The cloudflared daemon runs on your server and initiates an outbound connection to Cloudflare's edge. No inbound firewall rules are needed.

This means:

  • No origin IP to discover
  • No way to connect directly
  • No way to route through another CF zone
  • All traffic is forced to pass through YOUR Cloudflare zone — and therefore YOUR WAF, rate limits, bot rules, and Access policies

Alternative: Authenticated Origin Pulls

If you can't use Tunnel, enable Authenticated Origin Pulls — mTLS between Cloudflare's edge and your origin. Your origin verifies a client certificate that only YOUR zone presents.

This doesn't hide your origin IP, but it ensures that even if an attacker routes through Cloudflare, your origin rejects the connection because they don't have the right client certificate.

Checklist for Defenders

  • Origin server has no public IP (uses Cloudflare Tunnel)
  • OR: Authenticated Origin Pulls enabled with mTLS verification
  • No non-proxied subdomains leaking origin IP (check: dig +short mail.example.com)
  • Historical DNS records don't reveal origin (check SecurityTrails)
  • Origin TLS certificate doesn't leak in Shodan/Censys
  • NSG/firewall blocks ALL inbound except tunnel traffic
  • DNSSEC enabled on the domain

Our Automated Detection

Pentesting.se now automatically detects Cloudflare origin bypass vulnerabilities as part of the discovery scan:

  1. Identifies CF-proxied domains
  2. Probes common non-proxied subdomains (mail, ftp, cpanel, staging, dev)
  3. Checks Shodan for origin IP confirmation
  4. Tests origin accessibility on port 80 and 443
  5. Reports findings with specific remediation advice

This runs on every discovery scan — no manual configuration needed.

Alexander Norman is the founder of Adminor AB and Pentesting.se, a continuous security monitoring platform for Nordic businesses.