And to be clear, Cloudflare is useful. It can reduce DDoS exposure, proxy traffic, apply WAF rules, hide some infrastructure details, and make a public-facing application easier to defend.
The problem is not Cloudflare.
The problem is the assumption that being "behind Cloudflare" means the application has been meaningfully tested.
In real-world external security assessments, the serious issues often appear in the space between what a WAF is configured to protect and what is actually reachable from the internet.
Two patterns come up repeatedly.
— -
## Pattern 1: The Origin Server Is Still Exposed
A company migrates to Cloudflare. The main DNS record is proxied. The site works. The WAF is enabled.
But the original server IP is still reachable directly.
That matters because Cloudflare only protects traffic that passes through Cloudflare. If an attacker can send requests straight to the origin server, Cloudflare does not see the traffic at all.
This is not a theoretical edge case. Old DNS records, certificate transparency logs, passive DNS databases, internet-wide scanners, and hosting fingerprints can all reveal infrastructure that was meant to be hidden.
Once the origin is found, the attacker can test it directly. If the server responds with application content and does not show Cloudflare response headers, the security model has changed completely. The WAF is no longer part of the request path.
That is where forgotten admin panels, missing rate limits, exposed framework endpoints, and application flaws become much more dangerous.
In a typical ecommerce scenario, this kind of exposure produces a straightforward attack chain:
1. Find the origin through DNS history and internet scan data. 2. Confirm the origin accepts direct requests for the real hostname. 3. Discover an admin panel directly on the origin. 4. Confirm the login has no meaningful rate limiting or throttling. 5. Find an application-layer flaw — such as broken object-level authorization in an order API — and exploit it directly, with no WAF in the path.
The business risk is not "Cloudflare failed."
The business risk is that Cloudflare was treated as the full security boundary when the origin was still accepting traffic outside that boundary.
— -
## Pattern 2: Cloudflare Is Configured Correctly, but the Application Is Still Unsafe
The second pattern is more uncomfortable because the perimeter may look completely fine.
The production hostname is proxied. The origin firewall only allows Cloudflare IP ranges. Direct-to-origin traffic is blocked.
But a development or staging environment is publicly reachable — and nobody thought to apply the same controls.
A common version of this looks like:
1. Find a staging subdomain through DNS enumeration or certificate transparency logs. 2. Confirm it is publicly accessible with no VPN, no IP allowlist, and no authentication gate. 3. Discover debug mode is enabled, leaking stack traces and internal configuration details. 4. Test business logic that mirrors production — finding the same authorization flaws that exist in the main app, with none of the hardening. 5. Use findings from the staging environment to inform a more targeted attack against production.
The staging environment may even sit behind Cloudflare. The request path is technically correct. The proxy is working.
But a WAF cannot reliably determine whether a customer should be allowed to view another customer's order. It cannot know that a development API should not be public. It cannot fix unsafe database queries or decide that a debug stack trace reveals too much about the backend.
A request can look entirely normal to a proxy and still be dangerous to the business.
— -
## Why This Matters for Smaller Teams
For small businesses, ecommerce operators, and growing software teams, Cloudflare can create a false sense of completion.
The visible checklist looks good:
- CDN enabled - WAF enabled - SSL enabled - Bot protection enabled - Main domain proxied
Done. Ship it.
But attackers do not only test the main domain in the way the business expects. They look for forgotten hostnames, old IPs, staging environments, admin panels, debug pages, API endpoints, and authorization mistakes. They test the full shape of the external attack surface — not just the polished production homepage.
This is why "we have Cloudflare" and "we have been security tested" are not the same statement.
Cloudflare reduces certain categories of risk. It does not validate the application, the deployment model, the environment separation, or the authorization logic.
— -
## What Actually Helps
A better defensive approach starts with a simple question:
> What can an unauthenticated outsider actually reach in the first twenty minutes?
That question usually leads to practical checks:
- Review DNS history for old origin IP addresses. - Confirm origin servers do not accept public traffic directly. - Restrict origin ports 80 and 443 to Cloudflare IP ranges only. - Use Cloudflare Tunnel or Authenticated Origin Pulls where appropriate. - Audit every DNS record — not just the main site. - Put staging and development environments behind access controls, VPN, or IP allowlists. - Disable debug mode outside controlled environments. - Test business logic, authorization, and API behavior — not only scanner-visible issues.
The goal is not to abandon Cloudflare. The goal is to stop treating it as the entire security program.
WAFs are useful at the perimeter. But the real question is whether the perimeter matches reality — and whether the application remains safe when traffic actually reaches it.
That requires external review, application testing, and a willingness to look beyond the dashboard that says the WAF is on.
— -
The full technical version, including example recon commands, is published here: https://wardenbit.com/posts/cloudflare-is-not-enough-two-security-gaps-we-still-find-behind-the-waf.html