Cloudflare Pages & Workers: false sense of security for SaaS

"We're protected, we're behind Cloudflare"

This is the sentence we hear most often in audits. And it's exactly the problem. Cloudflare is an excellent CDN and a good WAF. But it protects your infrastructure, not your application. Business logic flaws, misconfigured APIs, and data exposures pass through Cloudflare like water through a net.

What Cloudflare actually protects

Cloudflare blocks DDoS attacks, some basic SQL injections, and known malicious bots. It hides your server IP and caches static content. It's a useful first line of defense.

What Cloudflare doesn't protect

Business logic flaws: if your API allows user A to access user B's data by changing an ID in the URL, Cloudflare lets it through. It's a valid HTTP request.

Unauthenticated APIs: an endpoint /api/users without authentication returns data through Cloudflare exactly like without Cloudflare. The WAF doesn't know this endpoint should be protected.

Data exposure in JavaScript: API keys, tokens, internal URLs in the JS bundle. Cloudflare serves these files efficiently — it doesn't analyze them.

Bypassing the Cloudflare WAF

Cloudflare's WAF uses signature-based rules. An experienced attacker bypasses these rules by encoding payloads, using syntactic variations, or exploiting endpoints that don't match detection patterns.

Moreover, default WAF rules are permissive. Most SMBs don't customize the rules and let entire categories of attacks through.

Origin IP exposure

Cloudflare hides your server IP behind its proxies. But this IP can leak through non-proxied subdomains (direct DNS records), emails sent from the server (SMTP headers), third-party services that log callback IPs, and configuration errors revealing the IP in HTTP responses.

Once the origin IP is known, an attacker bypasses Cloudflare entirely by accessing the server directly.

Cloudflare Access: the false barrier

Cloudflare Access protects URLs behind authentication. But the rules are often misconfigured. We find rules that protect /admin but not /admin/api, misplaced wildcards leaving paths open, and rules disabled after a development test.

Our recommendation

Keep Cloudflare — it's a good infrastructure protection layer. But never consider your application secure because it's behind Cloudflare. An external review tests your application through Cloudflare, exactly as an attacker would.