Tuning a Web Application Firewall So It Actually Blocks Attacks

Before letting any new rule set block traffic, run it in a logging-only mode against real production traffic for at least a week or two. This surfaces every false positive, a legitimate request pattern your rules would have blocked, before it actually blocks a real user. Skipping this step is how teams end up with a support ticket from a confused customer whose perfectly normal request happened to trip a rule tuned for a different kind of application entirely.

Generic rule sets are built to catch broadly known attack signatures, SQL injection patterns, common path traversal attempts, but they don't know that your application has a specific endpoint that legitimately accepts a large JSON payload, or a search field that legitimately includes characters a generic rule might flag as suspicious. Review your own application's actual traffic patterns and add targeted exceptions or custom rules for the specific behaviors that are normal for you but would otherwise get caught by an overly broad default.

A frequent mistake is fixing a false positive by switching off the whole rule or exempting an entire path, which quietly reopens the attack surface the rule existed to close. Narrow the exception instead: exempt only the specific parameter, endpoint, and expected payload shape that caused the block, and leave the rule active everywhere else. Write down why the exception exists and who approved it, then revisit it on a schedule. Exceptions that outlive the feature they were created for tend to become blind spots that nobody remembers adding.

A WAF is also a natural place to enforce rate limits against specific abuse patterns, credential stuffing against your login endpoint, scraping against your API, before that traffic ever reaches your application servers. This is cheaper and more effective than handling it in application code, since the WAF blocks the traffic before it consumes any of your compute. Set limits based on your actual legitimate traffic patterns for each endpoint, since a single global rate limit across your whole application will be too loose for sensitive endpoints and too tight for high-volume legitimate ones.

A WAF generates a log of every blocked request, and that log is only useful if someone actually reviews it on a schedule. Look specifically for patterns: repeated attempts from the same source against the same endpoint, which usually indicates a real, ongoing attack worth escalating, versus a one-off block that was probably a false positive worth adjusting the rule for. Skipping this review means you never learn whether your WAF is catching real threats or just generating logs nobody reads, which is close to the same as not having tuned it at all.

A tuning routine that gets a WAF from default rules to blocking safely:

1. Run the rule set in logging-only mode against real production traffic for at least a week or two.
2. Review every request it would have blocked and separate real attacks from legitimate traffic that merely looks unusual.
3. Add scoped exceptions or custom rules for behavior that is normal for your application, instead of disabling whole rule categories.
4. Set rate limits per sensitive endpoint, such as login, based on its actual legitimate traffic.
5. Switch to blocking, then review the blocked-request log on a schedule to spot ongoing attacks and remaining false positives.

A WAF inspects requests at the edge, which makes it effective against a specific category of attack, malicious input patterns, but it doesn't replace secure coding practices inside your application, patching known vulnerabilities in your dependencies¹, or proper authentication and access control. Treat it as one layer in a broader security posture, not the layer that makes the others optional. A WAF that's blocking obvious attacks while a known, unpatched vulnerability sits in a dependency behind it is still exposed.

Say your default rule set flags and blocks a customer's bulk CSV upload because its payload size and repeated field structure resemble a known scraping or injection pattern to a generic rule. Running that rule set in monitoring mode first would have surfaced this before it ever reached a real customer. The fix isn't disabling the rule category entirely, which would reopen the exact attack surface it exists to catch, it's adding a scoped exception for your specific bulk upload endpoint, its expected payload shape, and size range, so the rule still applies everywhere else it should.