Azure WAF: prevention vs detection mode (and the anomaly score)
Two modes with almost identical config screens and completely different consequences. One watches and writes everything down. The other stops the attack — and, if you rushed it, stops your customers too.
New to cloud? CAMPUX is a free, build-first course. Start here →
Detection mode logs what the WAF would have blocked but lets every request through; prevention mode actually blocks requests that breach the rules. The honest qualifier: you start in detection to tune out false positives, then switch to prevention — a WAF left in detection is a smoke alarm with the siren unplugged.
Every Azure WAF I have stood up has gone through the same two-step, and every one that skipped the first step caused an incident. The two modes are a single dropdown in the policy — Detection or Prevention — which makes it look like a trivial toggle. It is not trivial. It is the difference between a WAF that observes and one that enforces, and the mistake people make is treating that toggle as a light switch when it is really the last step of a process.
What each mode does to a request
Both modes run the exact same machinery. A request comes in, the WAF evaluates it against the managed ruleset and any custom rules you added, and it works out whether the request looks malicious. Up to that point, detection and prevention are identical — same rules, same scoring, same verdict written to the log.
The split is only in the final act. In detection mode, the WAF records its verdict and then forwards the request to your backend anyway. Every SQL-injection probe, every path-traversal attempt, every matched rule shows up in the logs with a "would have blocked" note — and every one of them still reaches your app. In prevention mode, the WAF acts on the verdict: a request that crosses the line is blocked (typically a 403), and it never touches your backend at all.
So detection is a security camera that only films. Prevention is the camera wired to a lock on the door. You want the lock. The reason you do not fit the lock on day one is that you have not yet learned which of your own staff it will accidentally shut out.
| Detection mode | Prevention mode | |
|---|---|---|
| What happens to a matched request | Evaluated and logged as a match, then passed through to your backend. Nothing is stopped. | Evaluated, logged, and acted on — blocked (usually a 403) or otherwise interrupted before it reaches the backend. |
| What it is for | Baselining and tuning. Seeing what enforcement would catch on real traffic, so you can spot false positives before they hurt anyone. | Actual protection. This is the state you are aiming for — the WAF earning its keep by stopping attacks. |
| The risk of running it | False sense of safety. It logs threats but blocks none of them; leave a WAF here indefinitely and you are paying for a guard who only takes notes. | False positives become outages. Untuned rules block legitimate traffic, and panicked teams often disable the whole WAF — worse than never deploying it. |
How the WAF decides: the anomaly score
Here is the part most people miss, and it changes how you read the logs. On the OWASP Core Rule Set (CRS 3.x, the managed ruleset behind both Application Gateway WAF and Front Door), a single rule matching does not automatically block the request. The ruleset uses anomaly scoring instead.
It works like a demerit system. Each rule that matches adds points to a running anomaly score for that request, and the number of points depends on the rule's severity. As of 2026, the common CRS weights are:
- Critical — 5 points (the SQL-injection and cross-site-scripting patterns)
- Error — 4 points
- Warning — 3 points
- Notice — 2 points
The WAF sums the points from every rule that fired, then compares the total against a threshold — 5 by default. If the score reaches the threshold, the request is actioned: blocked in prevention mode, or logged as "would block" in detection mode. Because one critical match is worth 5 and the threshold is 5, a single strong signal is enough to trip it — while a scatter of low-severity notices has to accumulate before the WAF cares.
Treat those exact numbers with suspicion and the model as settled. The point values, the threshold, and even whether your policy runs in this anomaly-scoring style are all CRS-version dependent, and Microsoft has shipped several ruleset versions. The idea — matches add up, the request is actioned when the sum crosses a line — holds across versions; the specific weights you should confirm against whatever CRS version your policy has deployed. Do not quote "5 points" to an auditor without checking your own ruleset first.
One rule matching is a data point, not a verdict. The WAF blocks on the sum, not the single hit.
This matters for a practical reason: when you read detection-mode logs, you are not looking for one damning rule. You are looking at which requests crossed the threshold and which rules stacked up to push them there. A legitimate request that trips three separate low-severity pattern rules can cross the line just as surely as a real attack that trips one critical rule — and telling those two apart is the entire job of the tuning phase.
The migration path: detection first, then prevention
The right sequence is not a matter of taste. It mirrors the same discipline you use everywhere else in cloud governance, and if you have done any policy work it will feel familiar.
- Deploy in detection mode. Put the WAF in front of the app, ruleset enabled, mode set to detection. Nothing is blocked yet — you are only turning on the camera.
- Read the logs against real traffic. Let it observe a representative stretch of genuine usage — a full business cycle, not ten minutes. Pull the WAF logs and find every request that hit the threshold. Some will be real attacks (good, leave those). Some will be your own customers doing normal things (these are the false positives).
- Add exclusions for the false positives. For each legitimate request the WAF flagged, find the rule ID and the field that tripped it, and write a scoped exclusion — exclude that specific field from that specific rule, not the whole ruleset. Precision here is the whole game. Re-test after each change.
- Switch to prevention. Only once the logs are clean of false positives do you flip the mode to prevention. Now the requests you have already confirmed are hostile get blocked, and the ones you have confirmed are legitimate sail through.
If that shape rings a bell, it should. It is the same move as Audit → Deny in Azure Policy: you run a policy in Audit to see what it would flag, you fix the things that were legitimately non-compliant, and only then do you promote it to Deny so it starts enforcing. Detection is Audit. Prevention is Deny. Same discipline, different service — watch before you enforce, so that when you enforce, you already know exactly what you are enforcing on. The same instinct shows up in how you stage traffic through a load balancer before cutting over: prove it on observed behaviour first.
The failure I have watched most often is not an attacker slipping past the WAF. It is a team switching straight to prevention on untuned managed rules, watching the WAF start blocking real customers — a JSON body here, a search box with a SQL-looking string there — and then, under pressure, disabling the entire WAF to make the pages load again. Now they have no protection and a false belief that "WAFs just break things." An untuned prevention-mode WAF that gets panic-disabled is worse than never deploying one, because it burns the organisation's trust in the control. Detection mode exists precisely so this never has to happen. Skipping it does not save time; it moves the cost to your worst possible moment.
Why a WAF blocks legitimate traffic
When prevention mode starts throwing 403s at real users, the cause is almost always a false positive from the managed OWASP rules, not a real threat. The rules are pattern-matchers, and modern apps send a lot of traffic that looks, to a pattern-matcher, exactly like an attack. A JSON request body with nested quotes. A base64 blob in a header. HTML pasted into a comment field. A product search for O'Brien that reads like the start of a SQL injection. Each of these can trip a rule, add anomaly points, and — if enough of them stack — cross the threshold.
The wrong response is to reach for the off switch. The right response is the tuning loop: open the logs, find the specific rule IDs that fired on the legitimate request, and add a narrow exclusion for that field or that rule. You keep every other rule enforcing at full strength and carve out only the one pattern that was hurting you. This is exactly the work detection mode is for — and it is why the sequence, not the toggle, is the actual skill.
So which mode should you be in?
Prevention. Always, eventually — a WAF that never blocks is theatre, and detection mode on its own protects nothing. But "prevention as the destination" and "prevention on day one" are different claims. You earn prevention mode by spending real time in detection mode first, reading your own traffic, and tuning until the only things left crossing the threshold are things you are happy to block.
If your WAF is in detection today, do not feel behind — you are in the correct first phase. The failure is not being in detection; it is staying there because prevention got tried once, broke something, and scared everyone off. Do the tuning, then flip it. If your WAF is already in prevention and you never ran the detection phase, that is the one to check tonight: pull the logs and see whether anything you are blocking is really a customer. This is the kind of production judgement — the sequence, the hedge, the log-reading — that separates someone who has configured a WAF from someone who has operated one, and it is what our skills radar keeps flagging on real security-adjacent job postings.
Common questions
What is the difference between detection and prevention mode in Azure WAF?
Detection mode evaluates every request against the rules and logs what it would have done, but lets the request through to your app either way. Prevention mode does the same evaluation and then acts — blocking, or otherwise interrupting requests that breach the rules. Same rules, same scoring; the only difference is whether the WAF enforces or merely watches. You run detection first to see what enforcement would catch, then switch to prevention once the logs are clean of false positives.
What is the anomaly score in Azure WAF?
On the OWASP Core Rule Set (CRS 3.x), the WAF does not block on a single rule match. Each matched rule adds points to a per-request anomaly score based on its severity — as of 2026 the common weights are Critical 5, Error 4, Warning 3, Notice 2. When the total crosses the threshold (5 by default, meaning one critical match is enough), the request is actioned in prevention mode or logged in detection mode. Exact weights and threshold are CRS-version dependent, so confirm against the ruleset you have deployed.
Should I run Azure WAF in prevention mode?
Yes — that is the goal, because detection mode blocks nothing. But do not start there. Deploy in detection mode first, read the logs for a representative period of real traffic, add exclusions and tuning for the false positives, and only then switch to prevention. Going straight to prevention on untuned managed rules is the reliable way to break legitimate traffic and get the whole WAF disabled in a panic — which leaves you worse off than a tuned WAF in detection.
Why is Azure WAF blocking legitimate requests?
Almost always a false positive from the managed OWASP rules. Rich payloads — JSON bodies, base64 blobs, HTML in a comment field, SQL-looking strings in a search box — trip pattern rules and add anomaly points until the request crosses the threshold. The fix is not to disable the WAF; it is to find the rule IDs in the logs and add a scoped exclusion for the specific field or rule, then re-test. This is exactly why you tune in detection mode before enforcing.