A web application firewall is one of the most effective protections a public application can have, and one of the most commonly switched off. The pattern is familiar: the WAF goes live in blocking mode, a rule flags legitimate traffic, logins or checkouts start failing, and someone disables it under pressure. Months later it is still off.

The fix is not a better rule set. It is a staged rollout that learns from your real traffic before it blocks anything.

1. Know what you are protecting

List every hostname and the kinds of traffic each one handles: pages, JSON APIs, file uploads, login and password reset, and webhooks from partners. Each of these behaves differently, and the last three are where false positives cluster.

2. Start in monitor mode

Every major provider lets rules match and record without blocking: count mode in AWS WAF, alert or log modes in Akamai and Cloudflare, depending on the product and plan. Turn on the managed rule sets this way first. Your users notice nothing, and you start collecting evidence.

3. Collect real traffic

Leave monitor mode running for one to two weeks so it sees normal weekly patterns: batch jobs, month-end activity, partner integrations and marketing campaigns. A day of traffic is not enough.

4. Separate attacks from false positives

Review which rules matched, on which paths, from which sources. Real attacks tend to look like scanning: many paths, odd user agents, known bad payloads. False positives tend to cluster on specific legitimate features, such as a rich-text editor, a search box that accepts code snippets, or a webhook that posts unusual JSON.

5. Write narrow exceptions

When a rule misfires, exclude that one rule for that one path or parameter. Do not disable the whole rule group, and do not exempt an entire hostname. Broad exceptions are how a WAF ends up technically on but protecting nothing.

6. Switch to blocking in stages

Move the highest-confidence rules to blocking first, then the rest in batches. After each step, watch error rates, conversion on key flows and support tickets for a few days before continuing.

7. Close the side door

A WAF only protects traffic that passes through it. If your origin servers accept requests from anywhere, attackers can skip the edge entirely. Restrict the origin so it only accepts traffic from your CDN, using provider IP allowlists, signed requests or a shared secret header.

8. Protect login separately

Credential stuffing uses valid-looking requests, so signature rules rarely catch it. Rate limits on login, password reset and sign-up endpoints, combined with bot protection, do.

9. Keep tuning

Applications change, and so does attack traffic. Review WAF matches monthly and after significant releases, and keep a change log of every exception and why it exists.

We have run this process on enterprise edge platforms in financial services. If you want help onboarding or tuning a WAF on Akamai, Cloudflare or AWS, see edge security.