We recently migrated a major media site's WAF from a legacy vendor to Imperva. Initial deployment with the recommended rule sets was... rough. Our legitimate traffic patterns triggered a flood of false positives, especially around our dynamic content API and asset delivery.
We spent about three weeks in a tuning phase. The goal was to maintain security but reduce the block rate for legitimate users to near zero. Here's the workflow that worked for us:
**Phase 1: Analysis & Baselines**
* Switched all relevant rules to `Monitor` mode for 72 hours during peak traffic.
* Used the Security Analytics dashboard to identify top triggered rules. The biggest offenders were:
* `100100`: SQL Injection - Comments Characterization
* `1013100`: Cross-site Scripting (XSS) - Event Handlers
* `980130`: Remote File Inclusion (RFI) attack attempt
**Phase 2: Targeted Tuning**
Instead of disabling entire rules, we used rule exclusions based on concrete evidence from logs. Most useful were exclusions for:
* **URI Paths:** Our asset delivery path (`/cdn/*`) was safe to exclude from certain injection rules.
* **Parameter Names:** Specific, known query parameters for sorting and filtering.
Example of a JSON exclusion we added via Terraform for the Imperva module:
```hcl
resource "incapsula_waf_security_rule_exception" "exclude_cdn_from_sql_comments" {
site_id = var.incapsula_site_id
rule_id = "100100"
exclusion_type = "url"
urls = ["/cdn/*"]
}
```
**Phase 3: Custom Rules**
We created a few positive security model rules for our core API endpoints, defining allowed HTTP methods and expected parameter patterns. This was more effective than just chipping away at the block list.
**Results after 30 days:**
* False positive blocks dropped from ~5% of traffic to under 0.01%.
* No legitimate user complaints post-tuning.
* Successfully blocked several real attack bursts (credential stuffing, scanner probes) with zero tuning needed on those threat actor patterns.
* Learned that Imperva's strength is in its granular logging, which makes this tuning possible, but you **must** commit to the initial analysis period. Don't just deploy and switch everything to block.
Biggest pitfall? Not involving the application team early. We needed their input to understand which parameters and paths were truly dynamic versus static. Next time, I'd run the `Monitor` phase *before* the cutover during a pilot period.