Our e-commerce platform's Cloudflare WAF was costing us more than just the subscription fee. The hidden tax was in customer support tickets and abandoned carts, driven by legitimate users being blocked during checkout. After a month-long analysis and tuning process, we achieved a 95% reduction in these false positives. The methodology was rooted in FinOps principles: measure, analyze, and optimize a resource—in this case, security rules.
The core issue was the default Managed Rulesets, particularly the OWASP Core Rule Set (CRS), being too aggressive for our specific application logic. We were seeing blocks from rules like 942100 (SQL Injection Detection) and 913100 (Scanner Detection) on benign patterns in our coupon codes and address fields. The key was not to disable rules outright, but to strategically tailor them.
Our process followed these steps:
* **Isolate:** We first created a custom WAF rule to log all requests to our checkout path (`/api/checkout`) without blocking. This gave us a clean baseline of legitimate traffic patterns.
* **Analyze:** In the Security Events log, we filtered for "Blocked" actions on the checkout path. We exported a week's worth of data and correlated blocked request IDs with our application logs to confirm false positives.
* **Iterate with Exceptions:** For each problematic CRS rule, we used **Tag-based exceptions**. Instead of disabling the rule globally, we added exceptions where the trigger matched our legitimate traffic pattern. For example:
* Rule ID: 942100
* Exception: If `http.request.uri.path` contains `/api/checkout` AND `http.request.method` is `POST` AND the triggered parameter `contains "coupon_code"`
* **Leverage Rate Limiting:** We replaced broad-based challenge/block rules on the checkout path with precise rate limiting. We set a high threshold (e.g., 50 requests per minute per IP) that would only catch brute-force attacks without affecting normal user flow.
* **Implement Score Thresholds:** We adjusted the sensitivity of the Managed Rulesets. We lowered the **Sensitivity Score** for our checkout path and increased the **Action** score threshold to "Block," allowing more requests to be scored and logged rather than immediately blocked.
The outcome was a security configuration that protected against true threats while becoming invisible to our customers. The side benefit was a reduction in unnecessary compute cycles on our origin servers from blocked traffic, a small but meaningful cost avoidance.
Optimize or die.
CloudCostHawk