Every CDN will sell you a web application firewall, and every managed ruleset ships with rules that will block something legitimate on your site: a file upload that looks like a payload, a CMS editor that submits HTML, an API client that sends SQL-shaped JSON. Flip the WAF straight to blocking and you find those collisions in production, through support tickets. The safe path is the same on every platform: observe, measure, except, then enforce in stages.
Why day-one blocking goes wrong
Managed rulesets are written for the whole internet, not for your application. Rules that detect SQL injection fire on legitimate search queries containing quotes; rules that detect cross-site scripting fire on WYSIWYG editors that legitimately submit markup; rules that detect path traversal fire on file managers and backup tools. The vendors know this, which is why every serious WAF has a non-blocking mode — Cloudflare calls the action Log, AWS WAF calls it Count, Akamai runs new policies in evaluation mode, and Fastly’s Next-Gen WAF was built around a monitor-then-block workflow. The mistake is not owning a WAF with false positives; every WAF has them. The mistake is discovering them after enforcement.
Stage 1: run everything in log-only mode
Enable the full managed ruleset with every rule set to log, count or monitor — whatever your platform calls the action that records a match without touching the request. Resist the urge to pre-trim rules you assume are irrelevant: the point of the observation window is to learn which rules fire on your real traffic, and a rule you removed is a rule you learned nothing about. If your platform scores requests rather than matching individual signatures (anomaly-scoring engines in the OWASP Core Rule Set tradition work this way), log the scores too, because your enforcement threshold will come from that distribution. Run the window across at least one full business cycle — two weeks is a reasonable floor, and it should include a deploy, a marketing send and whatever weekly batch jobs touch the site, because those are exactly the events that trigger unusual request shapes.
Reading the observation window
At the end of the window, pull the matched-request log and group it by rule ID, then by URL path, then by client. Three patterns emerge. Rules that fired only on obvious attack traffic — scanner user agents, requests for /wp-login.php on a site that has no WordPress, probes from a handful of ASNs — are safe to enforce. Rules that fired on a specific legitimate path, such as an upload endpoint or an editor, need a scoped exception. And rules that fired broadly across normal traffic need investigation before you touch enforcement at all, because they usually mean your application sends something rule authors considered suspicious, and a global disable may be more honest than a hundred path exceptions. Keep the numbers: matched requests per rule per day is the baseline you will compare against after every ruleset update. Our guide to reading a CDN log line covers the fields you will lean on here.
Exceptions before enforcement
Write exceptions as narrowly as the platform allows: this rule, on this path, for this parameter — not “disable rule group for the whole site.” A scoped exception keeps the rule protecting the other 99 percent of the application. Document each one with the ticket or log sample that justified it, because exceptions outlive the people who wrote them, and an undocumented exception is the first thing a future audit flags. This is also the moment to fix the application where fixing is cheaper than excepting: an API that accepts raw SQL fragments in a query parameter is a redesign candidate, not an exception candidate.
Staged blocking and the rollback plan
Enforce in stages, not in one switch. Start with the rules that matched only attack traffic, ideally on a low-risk hostname first, and hold each stage for a few days while you watch two numbers: blocked-request count by rule, and your business funnel (checkout completion, login success, API error rate). A false-positive incident shows up in the second set before anyone files a ticket. Keep the rollback path to log-only mode one click away and rehearsed — the ability to un-block in seconds is what makes aggressive enforcement safe. Once stable, schedule a quarterly review: rulesets update, applications change, and the exception list only stays honest if someone re-reads it. For choosing the engine itself, see our comparison of Cloudflare’s WAF and Akamai App & API Protector, and for the wider pre-launch checklist, the CDN security baseline.