What Is a WAF (Web Application Firewall)

A WAF (Web Application Firewall) is a filter that sits between the user and a web application (or an API) to inspect HTTP/HTTPS traffic and block requests that look malicious before they reach the server. Where a network firewall looks at IPs, ports and protocols, the WAF looks inside the HTTP request itself: parameters, headers, cookies, JSON body, upload payloads and known attack patterns. It is the control that turns a successful SQL injection into a silent 403, and the first defensive line that PCI DSS demands explicitly and NIS2 strongly recommends.

This guide explains what a WAF is, how it works internally, what kinds of attacks it really blocks, the common detection models, the deployment options, the mistakes we see repeated in audits and how it fits the main compliance frameworks.

What a WAF is

A WAF is a reverse proxy specialised in application security that inspects every HTTP/HTTPS request before forwarding it to the backend. Logically it sits in front of the application and applies rules to decide whether the request continues, is blocked, is throttled or is flagged for analysis.

What it brings operationally:

• Layer 7 attack blocking (OWASP Top 10) without touching the application code.
• Zero-day mitigation while the development team prepares a patch.
• Visibility into the real offensive traffic against the application: a good WAF console is the best source for understanding what tries to break the site every day.
• Rate limiting and bot management on sensitive endpoints (login, checkout, forms).
• Compliance with explicit requirements from frameworks like PCI DSS, NIS2 or ENS.

What a WAF is not: a substitute for secure development. If a penetration test finds an IDOR or broken authentication, the WAF won't stop it. Generic rules catch injections and XSS, not business logic flaws.

How a WAF works under the hood

A modern WAF combines three decision engines that rarely act in isolation.

Negative model (blacklist by rules)

The classic approach. The WAF loads a set of signatures (regex, patterns, known payload lists) and blocks any request that matches. ModSecurity with the OWASP Core Rule Set (CRS) is the historical reference: thousands of rules covering SQLi, XSS, RFI, LFI, command injection and more. Cloud WAFs (Cloudflare, AWS WAF, Akamai) also start from this model and add proprietary signatures updated daily.

Strong point: catches 80% of automated offensive noise with little configuration. Weak point: generates false positives when the application handles legitimate input that triggers signatures (text fields containing words like "select", "drop" or "union", for instance).

Positive model (whitelist by contract)

The WAF learns or is configured with the legitimate shape of each endpoint (expected parameters, types, lengths, allowed values) and blocks any request that falls outside that contract. On APIs it works very well if you have the backend's OpenAPI/Swagger specification: the WAF straight up rejects JSON bodies with unexpected fields.

Strong point: very high precision when the contract is kept up to date. Weak point: continuous maintenance is required. Any backend release that adds a parameter breaks the model if it is not updated.

Heuristics and ML

Today's WAFs (Cloudflare WAF, F5 Distributed Cloud, Imperva, AWS WAF Bot Control) layer in anomaly scoring, IP reputation, client fingerprinting and models trained on traffic from millions of sites. The final decision is not "regex matched", it is an accumulated score the operator tunes per endpoint.

Strong point: detects variants that signatures miss (obfuscated payloads, new evasions, bots rotating user-agents). Weak point: black box from the client side. The vendor decides what is anomalous and the traceability of a block is lower.

What a WAF actually blocks

The rules that deliver real value in production are always the same attack families:

• SQL Injection (OWASP A03:2021). UNION patterns, comments, time-based, error-based.
• Cross-Site Scripting (A03:2021). Injection of <script> tags, JS events in attributes, payloads obfuscated with HTML entities or JS encoding.
• Command injection and path traversal. Characters like ;, |, &&, ../, attempts to read /etc/passwd or web.config.
• Local/Remote File Inclusion. URLs pointing to local or external resources when the application processes dynamic paths.
• Server-Side Request Forgery (A10:2021). Requests trying to reach cloud metadata (169.254.169.254) or internal services.
• Insecure deserialisation. Known gadget payloads for Java, .NET or PHP.
• Anomalous HTTP headers and methods. Manipulated Host, ambiguous Transfer-Encoding (HTTP request smuggling), exotic methods.
• Bots and credential stuffing. Automated traffic patterns, leaked credential lists, known malicious agents.
• Layer 7 DDoS. Saturation of endpoints with formally legitimate requests. Here the WAF acts through rate limiting rather than signatures.

For vulnerabilities in the application itself that the WAF does not neutralise (business logic, IDOR, broken access control), the OWASP Top 10 2025 guide helps you understand what stays outside its reach.

Types of WAF by deployment

Five common models depending on where the WAF runs. Each one fits a different scenario.

Cloud / SaaS

Cloudflare, AWS WAF, Akamai, Fastly, Azure Front Door.

• Where it runs: in the provider's network, in front of DNS.
• Pros: fast deployment, automatic scaling, telemetry shared across tenants.
• Cons: TLS traffic transits the provider, external dependency.

Appliance / virtual

F5 BIG-IP ASM, Imperva SecureSphere, Fortinet FortiWeb.

• Where it runs: hardware or VM at the perimeter or in the datacentre.
• Pros: full control, no transit through third parties, minimal latency.
• Cons: high cost, manual scaling, hardware to maintain.

Host-based / embedded

ModSecurity on Nginx or Apache, NAXSI.

• Where it runs: as a module of the web server itself.
• Pros: zero or low cost, fully under team control.
• Cons: load on the server, no protection if the host goes down.

WAAP (Web App and API Protection)

A category that bundles WAF, bot management, API security and DDoS in a single cloud console.

• Where it runs: the provider's cloud.
• Pros: integrates API and bot protection into one product.
• Cons: a young category, vendor coverage varies.

RASP (Runtime Application Self-Protection)

• Where it runs: as instrumentation inside the application runtime.
• Pros: full context of the execution flow, low false positive rate.
• Cons: requires stack changes, does not cover bots or DDoS.

The choice depends less on the brand and more on the operational model. A small business with a public website on public cloud is usually well served by Cloudflare WAF on its Pro/Business plan. A financial entity with strict compliance typically combines an appliance WAF at the perimeter with a cloud WAAP for volumetric mitigation.

WAF, firewall, IPS and RASP

Four names that get mixed up frequently and that cover different layers.

• Network firewall. Layers 3-4. Decides by IP, port and protocol. Does not understand HTTP. Essential but blind to the payload.
• IPS (Intrusion Prevention System). Upper layer 4 and shallow layer 7. Inspects generic network patterns including some HTTP, but does not understand application context.
• WAF. Deep layer 7, specialised in HTTP/HTTPS. Understands parameters, cookies, JSON, multipart. The right control for attacks against applications and APIs.
• RASP. Inside the application. Sees the actual execution flow (which SQL query was built, which file is being opened). Lower false positives but requires instrumenting the runtime.

The same attack (SQL injection) can be touched by the IPS, watched by the WAF and, if it reaches that far, neutralised by the RASP at the last moment. Modern defensive architectures combine them rather than picking one.

Common mistakes in WAF deployments

What turns up in audits over and over:

1. WAF in "log only" mode for months. Valid as a tuning phase, dangerous if it stays that way permanently. If it never moves to "block", it does not protect anything.
2. Global rules without tuning for the application. Generic OWASP CRS signatures block legitimate fields in many applications (long forms, user-generated content, JSON payloads with strings that look like SQL). The team disables block mode instead of adjusting the rule and the WAF ends up as decoration.
3. TLS terminating before the WAF. If the WAF sits behind a load balancer that already decrypts and re-encrypts, review the chain. You want the WAF seeing cleartext traffic.
4. APIs without specific protection. Many deployments cover the front-end web and leave APIs behind paths like /api/v1/* with generic rules. For APIs the right move is WAAP with an OpenAPI schema loaded, or at minimum endpoint-specific rules.
5. Blocks are not monitored. The WAF log is the best source of offensive intelligence on the application, and most of the time nobody reads it. Send events to the SIEM and create alerts on new patterns.
6. Bypass via subdomain or origin IP. The attacker finds the real server IP (Shodan, old certificates, historical DNS records) and connects directly, skipping the cloud WAF. Mitigation: restrict the origin to accept traffic only from the WAF provider.
7. No custom rule management process. Rules get created ad hoc per incident and nobody reviews them. After months there are obsolete rules opening holes or duplicating logic. Document and review quarterly.
8. WAF as the only layer. The WAF mitigates, it does not replace secure development, strong authentication, CVE management or server hardening.

WAF and compliance

Frameworks where the WAF appears explicitly or very strongly:

• PCI DSS v4.0 (req. 6.4.2). For entities handling card data, requires either an automated technical solution that detects and prevents web attacks (a WAF in practice) or manual application reviews on a defined cadence. This is the framework that historically made the WAF de facto mandatory in e-commerce.
• NIS2 (article 21). Requires appropriate technical measures to manage risk. WAF qualifies as a standard measure for exposed applications, especially in essential sectors. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (article 9). For European financial entities, reinforces protection of critical applications and APIs.
• ENS (Spanish Royal Decree 311/2022, op.exp.4). Public sector applications exposed to the internet must have application-level filtering and monitoring controls.
• ISO 27001:2022 (control 8.23). Web and application filtering as a documented technical control within the ISMS.

For regulated audits, having a WAF is not enough. You have to document operating mode (block/log), active rules, the tuning process, generated events and integration with the SOC.

Frequently asked questions

Does a WAF replace web application penetration testing?

No. The WAF mitigates generic attacks and known signatures, but does not detect business logic errors, broken authorisation or custom flows. The pentest evaluates the application as it really is, including what the WAF does not touch. The two controls complement each other: the pentest finds the problem, the WAF contains it while it gets fixed.

Which WAF is best for a small or mid-sized business?

Depends on the stack. For a public site already behind Cloudflare, Cloudflare's own WAF (Pro or Business plans) covers 90% of cases. If the application sits on AWS, AWS WAF plus Shield Standard works well. For on-premise environments on a tight budget, ModSecurity with OWASP CRS on Nginx is still valid if there's a team to maintain it.

Does the WAF protect against DDoS attacks?

Partially. Cloud WAFs include layer 7 DDoS mitigation (application saturation) through rate limiting and bot management. For volumetric layer 3-4 DDoS (network saturation), you need a specific DDoS protection service from the provider (Cloudflare DDoS, AWS Shield Advanced, Akamai Prolexic).

Can a WAF generate false positives on legitimate applications?

Yes, especially with OWASP CRS untuned. Typical false positives appear on free-text forms, internal search, HTML/Markdown editors and APIs that accept JSON with long strings. The fix is per-endpoint tuning, not disabling block mode. An initial "detection only" phase of 2 to 4 weeks with daily review is usually enough to clean up the rules that fire on your legitimate traffic.

How is a WAF kept up to date?

Cloud WAFs update automatically with vendor signatures (including new rules after critical CVEs like Log4Shell or Spring4Shell). Appliance and host-based WAFs depend on the team: review the rule set changelog monthly (OWASP CRS publishes versions), test in staging, promote to production.

Which metric tells you a WAF is well configured?

Three signals: low false positive ratio in logs (under 1% of legitimate traffic blocked), active blocking of automated campaigns (botnets scanning vulnerabilities) and integration with SOC/SIEM with actionable alerts. If the WAF blocks a lot but nobody is looking, it is being underused.

Related resources

• What is a SOC (Security Operations Center): where WAF events go for continuous detection.
• What is SIEM and how it works: the platform that correlates WAF events with the rest of the telemetry.
• What is EDR (Endpoint Detection and Response): the endpoint complement to perimeter WAF.
• What is a CVE: vulnerabilities explained: how new CVEs translate into urgent WAF rule updates.
• JWT security: vulnerabilities and best practices: why a WAF will not catch a manipulated token without specific rules.
• OWASP Top 10 2025 business vulnerabilities: the catalogue of vulnerabilities a WAF tries to cover.
• What is a penetration test: what an audit finds that the WAF cannot stop.

WAF at Secra

At Secra we review WAF deployments as part of web and mobile application audits and infrastructure audits. The usual scope includes verifying operating mode (real blocking, not just logging), analysis of active rules, hunting for bypass via direct origin or unprotected subdomains, validation of the integration with SOC/SIEM and a tuning proposal tailored to the application's real traffic. If you want to validate your current WAF posture or need support designing the deployment, get in touch through contact.