Web Application Firewall Guide

A web application firewall only protects what it can see, parse and is allowed to block, and too many run for years in alert-only mode, with exclusions so broad they protect little, or in front of an origin server attackers can reach directly. Exploiting public-facing applications is a frequent way into organisations, and a well-run WAF buys time between a vulnerability becoming known and the code fix reaching production. This guide explains what a WAF does and does not do, deployment models, the OWASP Core Rule Set, managed and custom rules, virtual patching, tuning false positives, bypass risks at a high level, logging and metrics, and PCI DSS Requirement 6.4.2. It is vendor-neutral and written for application security, platform and SOC teams who deploy or operate WAFs.

Key takeaways

• A WAF is a compensating layer, not a fix: it reduces exploitation of injection and known flaws but does not remove vulnerabilities, broken access control or business logic bugs.
• Start in detection mode, then block: run new policies in detection, log-only or count mode, tune false positives with narrow exclusions, and move to blocking in stages with a tested rollback.
• Tune with exclusions, not thresholds: the OWASP Core Rule Set (CRS) warns that raising anomaly thresholds above the defaults lets many attacks through; exclude specific rules and parameters instead.
• Lock down the origin: a cloud or CDN WAF is bypassed entirely if the origin accepts traffic from anywhere; restrict it with authenticated origin pulls, secret headers, tunnels or allowlists.
• Logs make it a control: PCI DSS 6.4.2 requires a solution that generates audit logs and either blocks or raises an alert that is "immediately investigated"; send WAF logs to the SIEM and measure blocking coverage.

What a WAF does and does not do

A WAF inspects HTTP and HTTPS requests (and sometimes responses) at layer 7 and blocks or flags those that match attack patterns or break a defined policy. A network firewall filters by address, port and protocol; a next-generation firewall adds application identification and intrusion prevention, but usually lacks the HTTP parsing, application-specific rules and per-parameter tuning a WAF provides. MITRE ATT&CK lists WAFs under mitigation M1050 Exploit Protection for T1190 Exploit Public-Facing Application, noting they "may be used to limit exposure of applications". See the Firewall Management Guide for network firewall operations.

Deployment models

• ModSecurity: started in 2002 as an Apache module, transferred from Trustwave to OWASP in 2024 and now maintained as an OWASP project.
• Coraza: an OWASP Production Project written in Go, described as a "Drop-in replacement for ModSecurity" and "100% compatible with OWASP Core Rule Set", with connectors for Envoy, Caddy, NGINX and HAProxy.
• NAXSI: an NGINX module that "behaves like a DROP-by-default firewall" (a positive model). The original repository was archived on 8 November 2023 and points users to a maintained fork.

Choosing: a small organisation with a few internet-facing sites usually gets most value from a cloud or CDN WAF with managed rules, provided the origin is locked down. Large organisations typically run a cloud edge WAF for internet traffic plus gateway or ingress WAFs for internal and API traffic, managed as code from one policy repository. Regulated or latency-sensitive workloads that cannot send traffic through a third party favour reverse proxy or module deployments.

Rule sets: CRS, managed rules and custom rules

Positive and negative security models

A negative model blocks requests that match known attack patterns; it is quick to deploy but, as OWASP's virtual patching guidance puts it, "the possible evasions are more likely". A positive model allows only requests that conform to a defined specification (methods, paths, parameter types and lengths) and denies the rest. It is stronger but costs more to maintain, which makes it practical mainly for APIs with an OpenAPI schema and for high-value forms such as login and payment pages.

OWASP Core Rule Set

CRS is "a set of generic attack detection rules for use with" ModSecurity "or compatible web application firewalls", and many cloud WAF managed rule sets are based on it. The latest release listed on coreruleset.org in October 2026 is 4.30.0. A long-term support line, v4.25.x LTS, receives security fixes, regression fixes and critical PL1 false positive fixes "until Q3 2027", but never new rules or features: choose LTS where change control is slow, the regular releases where you want new detections.

CRS runs in anomaly scoring mode: matching rules add to a score instead of blocking directly, and the request is blocked when the score reaches a threshold. Default severities are CRITICAL 5, ERROR 4, WARNING 3 and NOTICE 2; default thresholds are 5 for requests and 4 for responses (tx.inbound_anomaly_score_threshold and tx.outbound_anomaly_score_threshold), so a single critical match blocks a request.

Each level adds rules to the one below. CRS separates the blocking paranoia level (rules that count towards the threshold) from the executing paranoia level, which runs higher-level rules that "will never count towards the anomaly score threshold". Raising only the executing level lets you see what a higher level would catch, and tune it, before enforcing it.

Managed versus custom rules

• Managed rules: written and updated by the WAF provider or a marketplace seller, often soon after a major disclosure and, one major cloud provider says, sometimes before it. The trade-off is visibility: the same provider's documentation notes that "you can't view all of the details for the individual rules within a rule group". Pin versions where the platform allows, and test new versions in count mode.
• Custom rules: your own logic for geography, IP reputation, rate limits, specific paths, headers or virtual patches. Many platforms evaluate custom rules before managed rules, so a broad custom allow rule can silently bypass all managed protection.

Virtual patching for CVEs

Virtual patching is "A security policy enforcement layer that detects and blocks matching exploitation attempts" without changing the vulnerable code, and OWASP is explicit that "It does not remove the underlying vulnerability". It works best for injection-type flaws and when the fix depends on a vendor or a slow release cycle. OWASP's process has six phases: preparation, identification, analysis, virtual patch creation, implementation and testing, and recovery and follow-up.

1. Prepare in advance: pre-approve an expedited change path for WAF rules, so an emergency rule does not wait for a weekly change board.
2. Write for the vulnerability, not the exploit: match the vulnerable parameter, path or behaviour; rules that block one public proof-of-concept string are evaded by the next variant.
3. Test in log-only mode first, then enforce, and ask for a retest of the vulnerability through the WAF.
4. Track and retire: record the rule ID against the ticket, and remove the virtual patch once the code or vendor fix is deployed and verified.

A virtual patch does not undo a compromise that happened before it was deployed. After ToolShell, stolen ASP.NET machine keys kept attackers inside after patching, so key rotation and hunting were needed as well. See the Zero-Day and Exploited Vulnerabilities Guide and the Patch Management Guide.

Bots, APIs and WAAP

Vendors increasingly sell WAF, bot management, API protection and layer 7 DDoS mitigation as one platform, often called web application and API protection (WAAP). The capabilities overlap but answer different questions.

• Bots: WAF signatures stop scanners and exploit attempts; credential stuffing, scraping and inventory hoarding send well-formed requests and need behavioural detection, client signals and rate limits. See the Bot Management Guide.
• APIs: enforce the API's schema (a positive model), content types, sizes and rate limits per client or token. Generic CRS rules often produce false positives on JSON APIs and miss authorisation flaws entirely. The McKinsey Lilli incident involved SQL injection in unauthenticated APIs: the class of flaw a tuned WAF should catch, on endpoints that required no authentication.
• Unknown endpoints: a WAF only protects hostnames and paths routed through it. Reconcile WAF coverage against external discovery. See the Attack Surface Management Guide.

Rolling out and tuning a WAF

1. Inventory and prioritise: list public-facing applications and APIs with owners, technology stack and data handled; start with those in PCI scope or handling personal data.
2. Route and lock the origin: put the application behind the WAF and restrict the origin to WAF traffic before relying on it (see the next section).
3. Deploy in detection mode: SecRuleEngine DetectionOnly in ModSecurity, detection mode in Azure WAF, or count actions in other cloud WAFs. Microsoft's guidance is to run a newly deployed WAF in detection mode "for a short period in a production environment". Set an end date: detection mode is a phase, not a configuration.
4. Tune from real traffic: review matches by rule ID, path and parameter; confirm false positives with the application owner; add the narrowest exclusion that works. CRS describes editing its rule files as "strongly discouraged": use runtime exclusions (ctl:ruleRemoveTargetById for one parameter on one path) placed before CRS, or configure-time exclusions (SecRuleRemoveById, SecRuleUpdateTargetById) placed after it. CRS ships exclusion packages for common applications such as WordPress, Drupal and Nextcloud.
5. Do not raise thresholds to make noise go away: CRS warns that raising the anomaly threshold above the defaults allows many attacks to bypass it.
6. Enforce in rings: switch low-risk applications to blocking first, then higher-traffic ones; use a custom block page with a reference ID so users and the help desk can report false positives.
7. Keep rollback simple: per-rule overrides to count, and a policy-level switch back to detection, both changeable in minutes and recorded. Manage policies as code with peer review so a rollback is a revert.
8. Raise paranoia deliberately: set the executing paranoia level one above blocking, tune what appears, then raise blocking.

Bypass risks and origin exposure

Most real-world WAF bypasses come from architecture and configuration rather than clever payloads. Check these at a high level during design and in every penetration test scope.

• Origin exposure: if the origin IP is reachable, attackers skip the WAF. Common leaks include DNS-only records, SPF and TXT records, mail sent from the same server, and historical DNS data, which is why one CDN provider recommends rotating origin IPs after onboarding. Protect the origin with authenticated origin pulls using your own client certificate, a tunnel with no publicly routable IP, secret header or token validation, and provider IP allowlists (which that provider rates as only moderately secure on their own).
• Parsing and normalisation differences: the WAF and the application may decode URLs, character sets, JSON, multipart bodies or duplicate parameters differently, and HTTP request smuggling exploits disagreements between proxies. Keep the WAF engine and rule set current, and test with the content types the application really accepts.
• Inspection limits: many WAFs inspect only the first part of a large request body or limit the number of headers and parameters inspected. Check the platform's limits and set oversize handling to block or alert rather than pass.
• Uncovered paths: alternate hostnames, legacy APIs, staging sites and WebSocket or gRPC endpoints that bypass the WAF route.
• Overbroad allow rules: trusted IP ranges, partner networks or "monitoring" user agents allowed to skip inspection.

Where identity fits

A WAF holds powerful non-human credentials: cloud roles that let it read configuration or logs, API keys used by CI/CD to push policies, client certificates and shared secrets for origin authentication, and TLS private keys at the edge. The Capital One breach turned a misconfigured WAF's own cloud role credentials into access to 106 million people's data. Give WAF roles least privilege, block instance metadata access from the WAF host where it is not needed, store policy deployment keys in a vault and rotate origin secrets. See the API Key Management Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

Logging, SIEM and metrics

• What to log: timestamp, client IP and forwarded-for chain, host, method, path, matched rule IDs and anomaly score, action (blocked, logged, challenged), policy version and request ID. Avoid logging full request bodies where they carry credentials or card data, or mask them.
• Where: forward WAF logs to the SIEM with application context. See the SIEM Guide and Log Management and Retention Guide.
• Detections worth building: a blocked exploit attempt followed by a successful request from the same source; spikes in blocks for one rule after a disclosure; requests reaching the origin that did not pass through the WAF; WAF policy changes, rule disables and new allow rules outside change windows.

PCI DSS 6.4.2 and framework mapping

PCI DSS v4.x Requirement 6.4.2 states: "For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks", which is installed in front of the applications and configured to detect and prevent web-based attacks, is "Actively running and up to date as applicable", generates audit logs, and is "Configured to either block web-based attacks or generate an alert that is immediately investigated." It became mandatory on 31 March 2025, replacing the option in 6.4.1 of meeting the requirement through application security assessments at least every 12 months. A WAF in detection mode whose alerts nobody investigates does not meet it. See the PCI DSS 4.0 Guide.

Common failure patterns

• Permanent detection mode: the WAF was deployed for an audit, set to log only "until tuned", and never switched to blocking.
• Exclusion creep: whole rules or rule groups disabled site-wide to fix one false positive on one form, removing protection everywhere.
• Reachable origin: the CDN WAF is configured perfectly, but the origin accepts direct connections from the internet.
• The WAF as an attack path: an over-privileged WAF host or role, as in the Capital One breach.
• Virtual patches that become permanent: the rule ships, the code fix never does, and the next variant of the exploit evades the rule.
• Unmonitored blocks: blocked exploit attempts against a known CVE are not escalated, so nobody checks whether earlier attempts succeeded before the rule existed.

Practitioner checklist

• Inventory public-facing applications and APIs and record which are behind a WAF, in which mode.
• Restrict every origin to WAF traffic using authenticated origin pulls, tunnels or secret validation, and test direct access.
• Run OWASP CRS or an equivalent managed set at PL1 minimum, PL2 for applications with personal or account data; keep default anomaly thresholds.
• Tune false positives with the narrowest exclusion, never by editing rule files or raising thresholds; review exclusions quarterly.
• Set an end date for detection mode and move to blocking in rings, with a tested per-rule and policy-level rollback.
• Pre-approve an emergency change path for virtual patches, and retire each one when the fix is verified.
• Check body inspection limits and oversize handling; cover alternate hostnames, APIs and WebSocket endpoints.
• Apply least privilege to WAF roles, policy deployment keys and origin secrets.
• Send WAF logs to the SIEM, alert on policy changes and origin traffic that bypasses the WAF, and track the metrics above.
• Document how the WAF meets PCI DSS 6.4.2: placement, update process, logs and alert investigation.

Standards and references

• OWASP CRS: Anomaly Scoring
• OWASP CRS: Paranoia Levels
• OWASP CRS: False Positives and Tuning
• OWASP: Virtual Patching Cheat Sheet
• MITRE ATT&CK: T1190 Exploit Public-Facing Application
• Microsoft Learn: PCI DSS Requirement 6 (requirement text including 6.4.2)
• OWASP: ModSecurity Project
• Cloudflare: Protect Your Origin Server

Related NHI Mgmt Group resources: Bot Management Guide · Zero-Day and Exploited Vulnerabilities Guide · PCI DSS 4.0 Guide · SIEM Guide · Attack Surface Management Guide