Testing WAF rules is a critical step before deployment, but doing it against a live, protected endpoint is a surefire way to get your IP banned by Cloudflare's global threat intelligence. The key is to isolate your testing environment while still using the same rule logic.
First, you need a detached testing setup. The most reliable method is to test against a local instance of the WAF engine or a staging environment with the WAF in "Log Only" mode.
**Prerequisites:**
* A staging site behind Cloudflare, with a test subdomain (e.g., `staging-test.yourdomain.com`).
* Access to the Cloudflare Dashboard for that zone.
* A dedicated testing IP, which you will later add to the Allow List.
**Step-by-Step Workflow:**
1. **Create a Test Rule in "Log Only":**
Navigate to Security > WAF > Custom rules. Create a new rule you intend to test. For the action, select *Log*. This ensures requests are evaluated and logged, but not blocked.
```xml
Expression: (http.request.uri.path contains "/api/v1/test") and (http.request.method eq "POST")
Action: Log
```
2. **Whitelist Your Testing Tool's IP:**
In Security > WAF > Tools, add your workstation's public IP (or your proxy's IP) to the IP Access Rules with an "Allow" action. This prevents other Cloudflare security features from blocking your probes.
3. **Configure Burp Suite:**
* Use the staging domain as your target scope.
* In the Project Options > Connections tab, consider using a **dedicated proxy IP** for testing (like a cloud VM) to avoid contaminating your primary IP if the Allow List fails.
* Leverage Burp's Repeater tool for precise, iterative testing.
4. **Craft and Send Test Payloads:**
Systematically test each rule. For a SQLi rule, send a request like:
```http
POST /api/v1/test HTTP/1.1
Host: staging-test.yourdomain.com
Content-Type: application/x-www-form-urlencoded
payload=1' OR '1'='1
```
Immediately check the Cloudflare Logs (Security > Events) or the Analytics > Security tab for your rule's `Log` events. Filter by the rule ID.
5. **Validate and Switch to Block:**
Once you confirm the rule triggers correctly on your test payloads, change the rule's action from *Log* to an appropriate action like *Block* or *Managed Challenge*. Re-run a test to confirm blocking works, then remove your IP from the Allow List.
**Critical Pitfalls to Avoid:**
* **Never test against production endpoints** without "Log Only" and IP allow-listing.
* **Rate Limiting:** Your Burp Suite intruder or scanner can trigger rate limit rules. Configure aggressive throttling between requests.
* **Rule Order:** Remember, WAF rules evaluate in order. Your new rule might be superseded by a broader, earlier rule. Test in the context of your full rule set.
This method provides a controlled feedback loop, letting you validate rule efficacy and precision without disrupting legitimate traffic or risking a ban.
benchmark or bust
benchmark or bust
Good procedure. But I'd argue your whitelist step 2 should come before step 1. If you craft a rule first, even in Log Only, a misfired test from your scanner could still trigger other, existing protective WAF rules and get your IP flagged before you ever add it to the allow list.
Always configure the IP allow list in the Tools section as your very first action. Then create your test rule.
Agree on the order. The existing rule base is a minefield you can't fully audit at a glance. A single managed rule in a group you've forgotten about, like the Cloudflare Managed "WordPress" rule set, will catch your payload and trigger an IP flag before you even get to your custom rule's log.
You also need to verify the allow list is actually scoped to the WAF and not just the IP Firewall. I've seen teams whitelist at the account level, then watch their staging tests still get rate-limited by the zone-level WAF because they didn't add the IP under Security > WAF > Tools.
MQLs are a vanity metric.
While the "Log Only" mode is a decent safety net in theory, I've found its reliability depends entirely on Cloudflare's sometimes unpredictable rule execution order. You can craft a beautiful log-only rule, but a single managed rule group you've left in "Block" mode elsewhere in the stack, maybe one you applied to the root domain and forgot about, will still swing its hammer on your test traffic. The logs might show your rule evaluated as "log," but the request never gets to it because a higher-priority managed rule already dropped the connection.
And let's be honest, how many of us have a truly isolated staging environment that perfectly mirrors production WAF configs? You're probably testing on a shared staging subdomain where other teams have deployed their own rules. Log-only feels like driving with the parking brake halfway engaged; you're still generating threat intelligence noise, and if your payload is nasty enough, you risk having your IP fed into their global reputation system anyway, allow list or not.
Just my 2 cents