Your Cloudflare WAF Is Probably Giving You False Security: A Nine-Point Audit

Your Cloudflare dashboard says "Protected". The security level is on High. The Managed Ruleset badge is green. None of it means what you think it means. We run Cloudflare audits on Magento 2 stores every few weeks, and the dashboard-says-yes-reality-says-no gap is consistent enough to be a trope. What a trained eye looks for isn't whether the rules exist. It's where the rules have been disabled, bypassed, or allowlisted into uselessness.

Below is the nine-point audit we run against a Cloudflare zone when a Magento 2 store is in scope. It maps to the Cloudflare product line as it stands in 2026. If you've got paid add-ons (Enterprise WAF, Advanced Rate Limiting, Custom Rules with a higher limit), the checks get richer, but the nine below apply at every tier.

TL;DR

• "Cloudflare Managed Ruleset: deployed" is not the same as "OWASP Core Ruleset: enabled". Most stores we look at have the second one turned off.
• A WAF-bypass rule that keys on a User-Agent string is bypassable by anyone who can set a User-Agent string. That's every curl command on the internet.
• Allowlisted IPs accrete over years and nobody deletes them. Most allowlist entries in older zones are someone's ex-colleague's home VPN.
• A Page Rule or firewall rule that disables WAF on a custom admin path, globally, without an IP scope, is the same as not having a WAF on that path.
• Rocket Loader enabled on a Magento 2 storefront is almost always breaking RequireJS flows in production, even if QA doesn't see it.
• TLS min 1.2+ and HSTS with includeSubDomains are PCI-DSS hygiene, not nice-to-haves.

Check 1: Is the OWASP Core Ruleset actually enabled?

The OWASP Core Ruleset is the one you actually want. The Cloudflare Managed Ruleset catches broad-stroke attacks, but OWASP is where SQLi and XSS signatures live. It's shipped as a separate toggle under Security → WAF → Managed Rules → OWASP Core Ruleset, and a surprising number of stores have it sitting at disabled because someone once hit false positives on a legitimate form submission and nobody circled back.

The consequence is that your application-layer protection against SQL injection is the application itself. If your Magento install has a vendor module with a raw-concat SQL statement in an admin controller (see The 7 Security Findings We See in Almost Every Magento 2 Code Audit, finding #3), the OWASP ruleset is what sits between that bug and the internet. Disabling it removes the belt, leaving only the suspenders.

How to check: Security → WAF → Managed Rules. "OWASP Core Ruleset" line should say Enabled. If it's disabled or set to Log-only, read the reason in the changelog and confirm that reason still applies. Most "false-positive" disables were temporary diagnostic flips that nobody flipped back.

Check 2: Do any firewall rules bypass the WAF based on User-Agent?

A User-Agent header is controlled by the client. Anyone can set it to any string. If your zone has a firewall rule shaped like if http.user_agent contains "SomeTrustedScanner" then action: Skip (All), that rule is a bypass anyone can invoke by curling with the matching UA string.

We've seen this two ways. Sometimes it's a legacy monitoring tool whose UA was allowlisted when the tool went into production, and never re-evaluated when the tool was replaced. The more expensive version is a bypass keyed on the zone's default Cloudflare-scraping bot UA, which means malicious traffic pretending to be Cloudflare itself is whitelisted through the WAF.

How to check: Security → WAF → Custom Rules. Sort by expression, scan for any match involving http.user_agent. Each hit needs a justification in the changelog. No justification, no rule.

Check 3: Are there allowlisted IPs in your zone you can't positively identify?

Cloudflare's Security → WAF → Tools → IP Access Rules (and equivalently, custom rules with a Skip action scoped to IP) accumulate over time. Contractors, monitoring services, support engineers, a developer's home VPN. Every one of them got added for a reason. Most of them stayed after the reason ended.

The audit move is simple and uncomfortable: go through every allowlisted IP in the zone and assign it an owner. Any IP without a clear current owner gets removed. We've found zones with IPs allowlisted five years ago for a support vendor that went out of business in 2020. We've also found zones where a specific suspicious IP address was explicitly allowlisted with a full WAF skip, and the person who added it was no longer at the company.

The specific case to watch for: an allowlist entry that was added during an incident ("this scanner is triggering rules, let it through for now") and never removed. Those entries are the worst of both worlds; whoever was attacking during the incident now has a permanent pass through your WAF.

Check 4: Admin path bypass with no IP scope

A common pattern in Cloudflare configs: a custom admin path (whatever yours is) gets allowlisted so admin users don't hit WAF false positives. The right shape for that rule is path matches /your-admin AND src_ip in known_office_IPs THEN Skip (All). The wrong shape is path matches /your-admin THEN Skip (All) with no IP scope.

The wrong shape disables WAF on your admin path for the entire internet. Every credential-stuffing bot, every admin-token fuzzer, and every drive-by SQLi scanner hitting the admin login endpoint sails through without WAF inspection. The rule is usually five-plus years old and predates the IP scope feature being easy to use.

How to check: Security → WAF → Custom Rules. Any rule that matches a path-expression starting uri.path starts_with "/admin" or similar, with action Skip, needs an IP source clause in the same expression. If it doesn't have one, the rule is a zone-wide admin bypass.

Check 5: Rocket Loader on a Magento 2 storefront

Rocket Loader defers JavaScript execution by rewriting <script> tags to load asynchronously after page render. It works for most sites. It's almost always broken for Magento 2, because Magento's storefront relies on RequireJS modules that expect synchronous script loading and specific execution order.

Turn Rocket Loader on and what breaks depends on the theme: minicart refresh silently failing, add-to-cart button doing nothing on the first click, checkout step transitions hanging, customer-data.js not populating. The symptoms are intermittent enough that QA doesn't reliably reproduce them; they show up in production logs as isolated error reports that nobody connects to a single cause.

How to check: Speed → Optimization → Rocket Loader. If it's On, turn it off and see whether any front-end metric moves. If it's Off, make sure no page rule is overriding it back on for specific paths. This is a five-second fix, but it requires someone to actually do it.

Check 6: TLS minimum version and HSTS

Two settings, both under SSL/TLS → Edge Certificates.

Minimum TLS Version must be 1.2 or higher. TLS 1.0 and 1.1 have known vulnerabilities (POODLE, BEAST) and are non-compliant with PCI-DSS 4.0. A store accepting payments on a zone with Min TLS 1.0 is a compliance problem the moment a PCI auditor looks at it. Getting to 1.2 is usually a one-click change; getting to 1.3-min is conservative and fine for most storefronts, aggressive for ones with heavy legacy-client traffic.

HSTS (HTTP Strict Transport Security) tells browsers to refuse HTTP connections for the zone. If it's disabled or max_age=0, a MITM attacker on an airport Wi-Fi can still serve HTTP pages to a customer who typed the bare domain. Enable HSTS with max_age: 31536000, includeSubDomains: true, and consider preload: true after testing. For an e-commerce store handling payment data, HSTS disabled is a real exposure.

Check 7: What does the edge do to marketing and layered-nav params?

Cloudflare's Cache Rules page lets you strip query parameters before the request reaches your origin. If you don't configure it, your Varnish sees every gclid, utm_*, fbclid, srsltid, _gl as a cache-key-relevant parameter, which means every ad click is a cold MISS. That's a performance problem, not strictly a security one, but it's the one check on this list that's also a Varnish problem.

For the edge-layer security implication: cache rules that strip params before they reach the origin also affect what Magento sees in $_GET. Stripping utm_* at the edge is fine (Magento doesn't care). Stripping a form-key or a CSRF-token parameter at the edge breaks Magento. We've seen overbroad strip rules accidentally delete parameters the storefront relied on, because someone configured "strip all tracking parameters" with a regex that matched too aggressively.

How to check: Caching → Cache Rules. List every rule that modifies the request URL or query string. Confirm the parameter list is explicit, conservative, and documented.

Check 8: Page Rules globally disabling security on admin-like paths

Page Rules (the legacy product) and Configuration Rules (the newer replacement) can override any zone setting per URL pattern. It's legitimate and useful; it's also where "disable WAF on a path for an incident" decisions go to become permanent.

The specific anti-pattern to scan for: a page rule with a /something-admin-like/* pattern that disables Security Level, Browser Integrity Check, or Bot Fight Mode for that path globally. The original intent was usually to keep admin traffic from being challenged. The effect is identical to check 4: you've turned off perimeter security for the admin path for the entire internet.

How to check: Rules → Configuration Rules (and Rules → Page Rules for legacy zones). Read every rule. Any rule that disables a security feature on an admin-adjacent path needs an IP scope in the matching clause. If it doesn't, fix it now.

Check 9: Rate limiting on the admin-token endpoint

Magento's REST API exposes /rest/V1/integration/admin/token for programmatic admin login. It's the endpoint a credential-stuffing bot hits if it knows it's targeting a Magento store. Cloudflare ships rate limiting as a separate product (free tier limited, paid tiers generous). Most zones we audit have no rate limit on /rest/V1/* at all.

A minimum-viable rate limit: 10 requests per minute per IP on POST /rest/V1/integration/admin/token, action: Block. More generous thresholds work for stores with legitimate integration partners, but the threshold should always be scoped to the endpoint, not applied zone-wide.

How to check: Security → WAF → Rate Limiting Rules. If the list is empty, you have no rate limiting. Add the rule above as a first pass. If there are rules, read each one and verify the threshold and scope make sense for admin token traffic specifically.

Related reading

• The 7 Security Findings We See in Almost Every Magento 2 Code Audit. Cloudflare hygiene pairs with application-code hygiene. Each compensates for gaps in the other, and neither is a substitute for the other.
• Dangling CNAMEs and Subdomain Takeover: The DNS Ghosts Haunting Old Magento Stores. HSTS with includeSubDomains interacts with your DNS zone in ways that matter; before you flip HSTS on, clean the DNS side.

The nine-point Cloudflare audit checklist

1. Confirm OWASP Core Ruleset is Enabled

   Security → WAF → Managed Rules. OWASP Core Ruleset must be Enabled (not Log-only, not Disabled). Any disabled status needs a current justification and a removal date; stale "temporary" disables should be re-enabled and the false positives triaged.

2. Remove every UA-based WAF bypass rule

   Security → WAF → Custom Rules. Grep the rule expressions for http.user_agent. Each hit is a bypass that any client can invoke by setting the header. Replace with IP-scoped rules or delete.

3. Re-justify every allowlisted IP

   Security → WAF → Tools → IP Access Rules plus custom rules with Skip action. Assign each entry an owner. Remove any entry without a current owner. Special attention to any entry added during an incident that never got removed.

4. Scope admin-path bypasses to office IPs

   Any Custom Rule matching an admin path (/admin, /your-admin, /adminhtml) with Skip action must include a src_ip clause. Zone-wide admin bypasses are the same as no WAF on the admin path.

5. Turn off Rocket Loader for Magento storefronts

   Speed → Optimization → Rocket Loader = Off. Confirm no Page Rule or Config Rule overrides it to On for any path. Re-test minicart, add-to-cart, and checkout step transitions after the change.

6. Set TLS min to 1.2 and enable HSTS properly

   SSL/TLS → Edge Certificates. Minimum TLS Version = 1.2 (or 1.3). HSTS enabled with max_age 31536000, includeSubDomains true. Enumerate subdomains for TLS coverage before flipping includeSubDomains.

7. Audit edge query-string manipulation

   Caching → Cache Rules. List every rule that strips or rewrites query parameters. Confirm the parameter list is explicit, documented, and doesn't strip form-key or CSRF-token params by accident.

8. Kill global admin-path security overrides in Page Rules

   Rules → Page Rules and Configuration Rules. Any rule that disables Security Level, Browser Integrity Check, or Bot Fight Mode on an admin-like path needs an IP scope or deletion.

9. Rate-limit the admin-token endpoint

   Security → WAF → Rate Limiting Rules. At minimum: 10 req/min per IP on POST /rest/V1/integration/admin/token, action Block. Review other /rest/V1/* endpoints for similar threshold rules.