A WAF is usually described as the thing that stops application-layer attacks. It holds when the traffic is distinguishable, and a flood of individually valid requests to a legitimate endpoint is not, which is precisely the case it is most often expected to cover. A DDoS test exists to find out which case you are in. It sits inline in front of the origin and inspects each HTTP request against a ruleset before deciding to pass it or drop it. Signature matches, reputation lists, rate rules, bot-management signals, and managed rule groups that target known application-layer flood patterns all feed that decision. When a request matches a block rule, it is dropped at the edge before it ever reaches application compute.
The detection surface: what the WAF gets to see
A WAF makes its keep-or-drop decision from a finite set of signals, and testing it means testing each one. Rate per source is the oldest and weakest on its own, trivially spread across a botnet. Stronger signals layer on top: TLS and HTTP fingerprints, IP reputation, bot management scores, and interactive checks such as a challenge or a JavaScript challenge that asks the client to prove it is a real browser. The question a test answers is not whether these features exist in the console, but which of them actually fire against traffic engineered to look legitimate on every signal at once.
Where the WAF sits: in the path, or beside it
A WAF can only inspect traffic that actually flows through it, and on most platforms it is a separate resource you provision and then have to place in front of the origin. The most damaging finding in a real test is often not a misconfigured rule but a WAF that live traffic never reaches: an edge policy protecting a hostname the DNS no longer points at, a load-balancer WAF that was never attached, or an origin still reachable on its raw IP around the whole edge. A ruleset can be flawless and still enforce nothing if the request takes a path that skips it.
Placement also decides which layer the WAF defends. An edge WAF at a provider's points of presence sees traffic before it enters the network; a WAF bound to a regional load balancer sees it later, after routing has already happened. A thorough test drives traffic at the public entry point the way a real client reaches it, follows the actual DNS and routing, and confirms which enforcement point, if any, the request truly passes through before it reaches origin compute.
The false green: enforce versus observe
Every managed WAF can run a rule in a mode that logs a match without dropping it. AWS WAF calls it COUNT, Azure calls it Detection, Cloud Armor calls it preview, and the effect is identical. A policy sitting in count or observe mode produces clean dashboards full of "detections" and stops nothing. This is the single most common WAF finding in a real test: a ruleset that looks complete in the console, every group present, quietly passing attack traffic straight to the origin because the rules were never promoted to enforce.
The other error: blocking real users
A WAF has two failure modes, and they pull in opposite directions. A false negative lets attack traffic through. A false positive blocks a legitimate user: a real customer gets a challenge they cannot pass, a 403, or a silent reset. The false-positive rate at the operating threshold is what decides whether an operator dares leave the WAF enforcing during an incident, or reaches for the off switch at the worst possible moment and sheds real revenue to stop an attack. A test that measures only the false-negative axis is measuring half the control.
What a WAF test validates
The output is a per-rule statement: for each managed group meant to defend a class of L7 attack, did the request stop at the WAF, or did it arrive at the backend with a log line trailing behind it. Alongside it sits the false-positive cost of enforcing at that threshold. Together they turn "we have a WAF" into a measured picture of what it actually blocks and what that blocking costs.
For how WAF behavior fits a structured resilience exercise, see DDoS resilience testing.