A WAF deployed on defaults commits both possible errors at once: it blocks legitimate customers whose behavior looks unusual, and passes attacks dressed in ordinary clothing. Tuning is not polish; it is the product.
The false positive tax
Default rules do not know your application. Legitimate payloads, rich text, file uploads, unusual but valid API calls, trip generic patterns, and every block is a customer having a bad day you will never hear about. The tax is silent, which is why it persists. The double failure is not a paradox but a single cause seen twice: generic rules encode a generic application, and yours is not generic in either its legitimate traffic or its attack surface.
The false negative risk
Attackers test against default rulesets by definition, because defaults are what most targets run. Application-specific rules, tightened to your actual endpoints and payloads, are what raise the cost of attacking you specifically. The silence has a measurement fix: track WAF blocks against conversion and support-ticket data, because blocked customers do not file tickets with the WAF team, they abandon carts and email support about errors.
API traffic deserves special mention because it inverts WAF assumptions. Rules built for browser traffic, forms, cookies, session patterns, fit machine-to-machine traffic badly: legitimate API calls look anomalous to browser-shaped rules while API-specific attacks, broken object level authorization chief among them, sail past pattern-matching entirely. If APIs carry a meaningful share of your traffic, the WAF conversation must include API-specific protection with schema awareness, or a dedicated layer for it. A browser-era ruleset guarding an API estate is fitted to the wrong decade of your own architecture.
What tuned looks like
An initial learning period in detection mode, rules fitted to real traffic, exceptions documented rather than accumulated, and a quarterly review cadence because your application keeps changing. Fitted, then kept fitted, is the standard our security page promises for a reason. Attackers reading the same documentation as defenders is the oldest asymmetry in security, and custom rules are the cheapest way to step outside the shared script.
In practice
Run one week in detection-only mode on your riskiest ruleset and read what would have been blocked: the legitimate traffic in that log is your false-positive tax, itemized. Then tighten rules endpoint by endpoint, document every exception with an owner and a review date, and calendar the quarterly re-fit. A WAF is not a product you own but a garden you keep, and the keeping is measured in hours per quarter, not headcount.
A WAF tune-up is among the highest-return small engagements we run: fewer blocked customers, fewer passed attacks.