Just found this the hard way. If you set a Page Rule to "Cache Everything" or "Bypass Cache" with a URL pattern that matches your protected assets, it can bypass your active WAF rules for those requests.
The WAF evaluates before Page Rules, but a Page Rule that changes caching behavior seems to skip the WAF phase entirely for matched traffic. So if you have a rule blocking specific user agents or SQLi patterns, a matching Page Rule can punch a hole right through it.
Check your Page Rules. If you're using them for performance tweaks on admin paths or API endpoints, you might have accidentally disabled your security layer.
Trust but verify.
This is a documented behavior in their architecture diagrams, though it's often overlooked. The WAF operates at the L7 firewall phase, while Page Rules that alter caching behavior directly influence the traffic flow before it reaches that phase for a second evaluation.
I've validated this by analyzing raw logs from zones where we had aggressive OWASP paranoia mode enabled. Requests matching a `*example.com/api/*` "Cache Everything" rule showed zero WAF rule triggers, while otherwise identical traffic to non-cached paths was correctly blocked. The mitigation is to never use broad caching Page Rules on paths that require inspection; use the "Cache Level" setting within a WAF custom rule instead, as that applies within the security context.
You can test your own configuration with a simple curl command using a known-bad user agent string against the cached path versus a non-cached one. The discrepancy in HTTP response headers will confirm the bypass.
Show me the numbers, not the roadmap.