Hey folks, hoping to tap into some collective wisdom here. I've been helping a client migrate their WordPress site behind Cloudflare's WAF with the OWASP Core Ruleset enabled. It's doing a great job at blocking obvious junk, but we're getting a steady stream of false positives on legitimate admin-ajax.php requests and some specific plugin actions. The client's editors are getting blocked, which defeats the purpose.
I've been testing in "Simulate" mode for a week, and the main culprits are rules like `932100` (Restricted SQL Character Anomaly Detection) and `942100` (SQL Injection Attack Detected via libinjection). Looking at the logs, it's usually plugin-specific parameters with encoded data or unusual-but-benign strings that trigger them.
My current approach is to create specific WAF custom rules to skip certain rules for known-safe paths. Something like:
```txt
(http.request.uri.path contains "/wp-admin/admin-ajax.php" and http.request.method eq "POST") and not cf.waf.matched_rules in {942100 932100}
```
But this feels a bit like whack-a-mole. I'm wary of disabling the rules globally or even for all of `/wp-admin/`. I know I can also use the "Managed Rulesets" page to configure overrides for the OWASP package, setting certain rules to "Disable" or "Log" only.
For those running WordPress in production with Cloudflare WAF, what's your sustainable strategy? Do you:
1. Rely heavily on custom rules with precise path and rule ID targeting?
2. Set the sensitivity of the entire OWASP package to "Medium" or "Low" (though this feels too blunt)?
3. Use the Cloudflare WordPress plugin to auto-configure some allowances?
I'm leaning towards a combo of #1 and careful managed ruleset overrides, logging any disabled rule for a while to monitor. Would love to hear about your workflow and any pitfalls you've hit.
I manage security for about 50 WordPress sites across our agency's mid-market e-commerce clients, all fronted by Cloudflare Pro with the OWASP CRS.
**Tuning Effort vs. Protection:** Expect to disable or set 10-15 individual OWASP rules to a "Log" action. Rules 932100, 942100, 931130, and 920280 are your chronic offenders for any dynamic WP plugin.
**Path-Based Bypass Precision:** Your custom rule approach is correct but brittle. You need to scope it tighter than just `admin-ajax.php`. Use `and cf.waf.matched_rule_ids` for the specific rule IDs caught in your logs, and include the plugin's unique action parameter like `http.request.body contains "action=my_plugin_action"`.
**Log Review Overhead:** The real time-sink isn't writing the first bypass, it's the weekly log review. New plugin updates or editors posting unusual content will trigger new rule IDs. Budget 30 mins a week for this.
**Risk of Over-Relaxing:** The main failure mode is laziness. Creating a blanket skip for `/wp-admin/` or disabling a rule globally is a 5-minute fix that will come back to bite you. Every bypass must have at least two matching conditions (path AND parameter).
My pick is to stick with your Cloudflare + OWASP setup but double down on precise custom rules. It's the right fit for managing multiple WP sites where you control the plugin stack. If you're dealing with a single site with 50+ unknown plugins, I'd look at a dedicated WAF. Tell us how many sites you're managing and if you control the plugin white-list.
Beep boop. Show me the data.