WAF - observation, shadow and enforcement

A well-run WAF is not a box you switch on: it is a program that starts by observing, validates each rule in shadow and only then blocks, with an owner and a metric for every decision.

Cloudflare WAFOWASP Core Rule SetAWS WAFModSecurity

What it is

A WAF () inspects HTTP traffic at layer 7 and decides, request by request, whether it proceeds, is challenged, is limited or is blocked. It sees what a network firewall does not: path, method, headers, parameters and the request body.

It does not fix the application. Its role is to reduce the exposed surface and buy time: block known attack patterns, apply a "" while the team fixes the real flaw, and contain abusive automation before it reaches the origin.

Negative model and positive model

The negative model blocks what looks bad: , and path traversal signatures, as in managed rules (OWASP Core Rule Set and the rulesets maintained by the vendor). It is the ready-to-use baseline, but it generates false positives and can be bypassed by anyone who knows the pattern.

The defines what is valid and blocks the rest: for a critical endpoint, which methods, paths, content types and sizes are accepted. It gives much more precision, but requires knowing the application, so it is applied endpoint by endpoint, starting with the most critical (login, payment, administration).

Negative: broad and fast coverage, more noise, updated by the vendor.
Positive: high precision and minimal surface, higher maintenance cost, written by whoever knows the application.
In practice they are combined: the managed set as a safety net and the positive model on the endpoints that matter most.

Observation, shadow and enforcement

The golden rule is to never switch a new rule straight to blocking. The safe path has three phases:

Observation: the rule only logs (log action). You measure how much traffic it would catch and from whom.
Shadow: the rule runs in parallel and the simulated decision is compared with reality (what would have been blocked and was legitimate?). This is where precision is tuned.
Enforcement: the rule starts to act, beginning with a challenge instead of a hard block when in doubt, and gets an owner and a false positive metric.

Example: rules in Cloudflare's expression language

Two illustrative rules. The first is positive: on an orders endpoint, only GET and POST are accepted. The second protects login: login requests coming from outside a trusted list get a challenge. The field names follow Cloudflare's rules language; adjust to your environment.

custom rules - illustrativetext

# 1) positive model: unexpected method on /api/orders
(http.request.uri.path eq "/api/orders" and not http.request.method in {"GET" "POST"})
  -> action: Block

# 2) login outside the trusted list gets a challenge
(http.request.method eq "POST" and http.request.uri.path eq "/api/login" and not ip.src in $trusted_ips)
  -> action: Managed Challenge

# observation phase: same expression, only logging
  -> action: Log

False positives are the real cost

Blocking a legitimate customer costs revenue and trust, and it is what makes teams turn off the WAF. That is why each rule needs a precision metric, a documented exception (with an expiry) and a weekly review cycle. A WAF nobody tunes becomes, within a few months, either a wall that gets in the way or an ornament that blocks nothing.

WAFweb application firewallAn edge filter that blocks known attack patterns in HTTP. It complements the code: it does not replace fixing the vulnerability, it only buys time.see in glossary →Virtual patchvirtual patchingWAF rule that blocks exploitation of a known vulnerability while the real fix has not yet reached the application. It buys time, it does not eliminate the flaw.see in glossary →SQL injectionSQLiInput concatenated into a SQL string is parsed as part of the query. Parameterized queries send the values separately and remove the problem.see in glossary →XSScross-site scriptingInjection into a web page: untrusted input is rendered as HTML or script in another user's browser. Escape on output by context and add a Content-Security-Policy.see in glossary →Positive modelallowlistDefine what is valid for an endpoint (methods, paths, formats, sizes) and block everything else. More precise than signatures, but requires knowing the application.see in glossary →

connections on the map

Detection engineeringgenerates rulesWAF - observation, shadow and enforcement
WAF - observation, shadow and enforcementexecutesRunbooks, response and post-incident hardening
SOC SLOs and continuous tuningmeasures precisionWAF - observation, shadow and enforcement
Defense in depth: edge system designpositionsWAF - observation, shadow and enforcement

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Release strategies and rollbackdevopsobservation, shadow and enforcement: the same gradual ladder
DASTappsecfinds the flaw; the WAF mitigates it until it is fixed (virtual patching)