A web application firewall inspects HTTP and HTTPS traffic at Layer 7 and blocks requests matching known attack signatures. It reduces exposure to automated exploitation and common injection attacks. It cannot stop business logic flaws, access control vulnerabilities, or targeted attacks using encoding and obfuscation techniques to bypass its ruleset. It requires penetration testing to validate.
What is a web application firewall?
A web application firewall analyses HTTP and HTTPS requests at the application layer (Layer 7 of the OSI model). A traditional network firewall controls traffic based on source and destination IP address, port, and protocol. It has no visibility into request content. A WAF reads the content: URLs, headers, cookies, query strings, and POST body data. It compares that content against a ruleset and either passes, blocks, or challenges the request.
Three main deployment models exist. Cloud-based WAFs such as Cloudflare WAF and AWS WAF sit in front of your origin server at the DNS or CDN level. Traffic routes through the provider's network before reaching you. Appliance-based WAFs are hardware or virtual devices deployed within your own infrastructure, common in enterprise data centres. Host-based WAFs such as ModSecurity running on a web server inspect traffic at the server level without requiring a separate network device.
Detection logic falls into two categories. Signature-based detection compares requests against a library of known attack patterns. The OWASP Core Rule Set (CRS), the default ruleset for ModSecurity and compatible WAFs, contains rules covering SQL injection, cross-site scripting, command injection, and path traversal. Anomaly-based detection builds a baseline of normal traffic behaviour and flags statistical deviations.
Most commercial WAFs combine both: signature rules for known threat patterns, anomaly scoring as a secondary filter.
What does a web application firewall protect against?
A WAF provides meaningful protection in several categories.
Known attack signatures. SQL injection payloads such as ' OR 1=1-- and reflected XSS payloads such as are well-catalogued. A WAF with an up-to-date ruleset blocks the most common variants, reducing successful automated scans and opportunistic exploitation attempts. The OWASP CRS 4.x covers over 200 SQL injection rule variants across its 942xxx rule range.
Application-layer DDoS. Rate limiting at the WAF layer absorbs floods of HTTP requests targeting a single endpoint. A login page or search function that would exhaust application servers under high request volume can be protected with per-IP and per-session thresholds configured at the WAF.
Malicious bot traffic. WAFs with bot management features distinguish legitimate crawlers from credential-stuffing bots, scrapers, and vulnerability scanners. Cloudflare's WAF includes an exposed credentials check feature that cross-references login attempts against known breached credential databases.
Virtual patching. When a vulnerability is discovered in your application or a third-party component, a WAF rule blocking exploitation of that vulnerability buys time until the underlying code is patched. This decouples the detection timeline from the remediation timeline. For organisations with slow release cycles, virtual patching is one of the most operationally valuable uses of a WAF.
Automated scanning reduction. Commodity scanning tools and script-kiddie tooling generate large volumes of attack traffic. A well-configured WAF absorbs most of it before it reaches your application servers. This reduces noise in your application logs and limits the exposure window for mass-exploitation events.
What are the limitations of a web application firewall?
This is where most WAF deployments fall short. Several attack categories are not addressable by inspecting HTTP traffic patterns, regardless of WAF configuration quality.
| Attack category | WAF covers? | Why |
|---|---|---|
| SQL injection (common signatures) | Partially | Blocks known payloads; bypass techniques evade most rulesets |
| Reflected XSS (common payloads) | Partially | Signature-matched; obfuscated vectors evade detection |
| Application-layer DDoS | Yes | Rate limiting is effective |
| Malicious bot traffic | Partially | Bot management helps; distributed attacks evade rate limits |
| Virtual patching | Yes | Effective temporary mitigation |
| Business logic flaws | No | WAF cannot model application semantics |
| IDOR / broken access control | No | Requests look syntactically valid |
| Credential stuffing | No (rate limiting only) | Valid credentials, no injection payload to match |
| JWT manipulation / auth bypass | No | Token is structurally valid; flaw is in application logic |
| Serialisation attacks | No (limited) | Payloads easily obfuscated |
| Zero-day vulnerabilities | No | No signature exists until after public disclosure |
Business logic flaws
A WAF inspects the syntax of requests. It cannot understand the semantics of your application. If a user skips the payment confirmation step in a checkout flow by replaying an earlier session state, that request looks syntactically normal. The HTTP method is correct, the parameters are valid, the endpoint exists. The WAF passes it.
The same applies to price manipulation, quantity overflows, discount code abuse, and order state manipulation. These vulnerabilities are specific to your application's logic, and no generic ruleset can cover them. Read more about why these vulnerabilities evade automated tooling in business logic vulnerabilities: what scanners miss.
Broken access control and IDOR
Insecure Direct Object References occur when an application uses a controllable value, typically a numeric ID or UUID, to retrieve a resource without verifying that the requesting user is authorised to access it.
A request such as GET /api/v1/invoices/8471 is syntactically normal. The authentication token is valid. The endpoint exists. The parameter is an integer. The WAF passes it. The vulnerability is that the requesting user is not the owner of invoice 8471.
IDOR consistently ranks among the most frequently exploited access control vulnerabilities in web application penetration testing engagements. Mapping an application's data model and verifying authorisation at every access point requires a tester. A WAF cannot do this.
Authentication and session attacks
Credential stuffing attacks use lists of username and password pairs from previous breaches, testing them against your login endpoint. Each individual request contains valid, syntactically correct credentials. There is no injection payload. Rate limiting at the WAF layer can slow credential stuffing, but a well-configured attacker distributes requests across IP addresses and user agents to stay below rate thresholds.
Session fixation, JWT manipulation with a structurally valid token, and multi-factor authentication bypass through logic flaws follow the same pattern. The requests look legitimate because, from a protocol perspective, they are.
Zero-day vulnerabilities
A WAF blocks attacks matching known signatures. A zero-day vulnerability has no signature yet. The 2019 Capital One breach illustrates this. The WAF was active. The specific server-side request forgery (SSRF) path traversal pattern used to query the AWS EC2 metadata service was not covered in the active ruleset. The attacker obtained IAM credentials and accessed S3 buckets containing over 100 million customer records. WAF present. WAF insufficient.
The only reliable protection against zero-day vulnerabilities is secure application design: input validation at every boundary, parameterised queries, least-privilege access controls, and defence-in-depth that limits what any single vulnerability can achieve.
What WAF bypass techniques do attackers use?
WAF rulesets match patterns. Attackers modify their payloads to produce the same attack effect while evading the pattern. These are not theoretical techniques. They are standard methodology in offensive security engagements, and experienced testers apply them within hours of identifying a WAF.
Double URL encoding
Standard URL encoding converts ' to %27. A WAF decodes %27, identifies it as a single quote, and blocks the request. Double encoding encodes the % character itself as %25, producing %2527.
Standard (blocked): GET /search?q=test%27+OR+1%3D1--
Double-encoded: GET /search?q=test%2527+OR+1%253D1--The WAF decodes %2527 to %27 and sees a literal string. If the application or its underlying framework performs a second decode, %27 becomes ' and the injection succeeds.
HTTP parameter pollution (HPP)
HTTP allows duplicate parameter names. WAF and application may handle duplicates differently.
GET /search?id=1&id=2%27+OR+1%3D1--Some WAFs inspect only the first id value (1, clean). The application uses the last value or concatenates both. The injection reaches the application because the WAF evaluated the wrong instance.
Chunked transfer encoding
HTTP/1.1 Transfer-Encoding: chunked splits the message body into segments. Some WAFs inspect individual chunks rather than reassembling the full body before analysis.
Transfer-Encoding: chunked
4\r\n
' OR\r\n
6\r\n
1=1--\r\n
0\r\nNeither chunk (' OR or 1=1--) triggers a rule in isolation. The application reassembles and processes the complete payload.
SQL comment insertion and case variation
-- Original (blocked):
UNION SELECT username,password FROM admin--
-- Bypass variant:
UnIoN/**/SeLeCt/**/username,password/**/fRoM/**/admin--WAF rules that require SQL keywords to be adjacent to whitespace, or that are case-sensitive, are bypassed by inserting SQL comment blocks (/**/) between keywords and varying capitalisation. The database parses both forms identically.
For a detailed look at how these bypass techniques interact with SQL injection specifically, see SQL injection explained.
The result in most engagements: the WAF slows unsophisticated automated scanning. It does not stop a skilled attacker who understands WAF evasion. In many engagements, WAF bypass is achieved within the first day.
How do penetration testers validate a WAF?
During a web application penetration test, WAF effectiveness is assessed as a standard component, not an add-on.
The methodology covers several areas. First, testers identify whether a WAF is present and characterise the product and configuration by examining response patterns, error messages, and behaviour under anomalous input. Second, testers attempt to bypass WAF rules using the encoding, obfuscation, and protocol manipulation techniques described above, documenting which techniques succeed against which rule categories. Third, testers assess the full application attack surface including business logic, IDOR, authentication, and session management vulnerabilities that the WAF cannot cover regardless of its configuration.
The output is specific: which attack categories the WAF blocked in practice, which bypass techniques succeeded and for which payloads, which vulnerability categories the WAF does not address at all, and remediation recommendations for both WAF configuration and underlying application code.
For a comparison of how manual penetration testing differs from automated scanning approaches, read SAST vs DAST vs penetration testing.
How should you configure a WAF?
If you are deploying or reviewing a WAF, four configuration decisions have the most significant impact on effectiveness.
Enable blocking mode. Most WAFs default to detection (count/log) mode, which logs attacks without blocking them. Detection mode provides no runtime protection. Set blocking mode after an initial tuning period. Gartner research has identified detection-only mode as the most common WAF misconfiguration in enterprise deployments.
Tune rules to reduce false positives. An overly aggressive WAF blocks legitimate traffic and disrupts users. Teams under operational pressure often respond by disabling rules or reverting to detection mode. The OWASP CRS uses paranoia levels (1-4): level 1 is appropriate for most production applications with minimal tuning; levels 3 and 4 require systematic per-endpoint adjustment of anomaly score thresholds. Proper tuning keeps the WAF in blocking mode without operational disruption.
Review WAF logs. The WAF log is a source of threat intelligence. Patterns of blocked requests reveal which vulnerabilities attackers are actively probing, which IP ranges are targeting specific endpoints, and whether a specific endpoint is receiving unusual attention. Most organisations deploy a WAF and review the logs infrequently or not at all.
Maintain rulesets. Cloud-based WAFs with managed rules (Cloudflare, AWS WAF) update automatically. Organisations running ModSecurity or appliance WAFs need a process to update the OWASP CRS and vendor rulesets on a regular schedule, and immediately when a new vulnerability affecting their stack is disclosed.
Frequently asked questions
What is the difference between a WAF and a firewall?
A traditional network firewall operates at Layers 3 and 4. It controls traffic based on source and destination IP address, port, and protocol. It has no visibility into the content of HTTP requests. A web application firewall operates at Layer 7. It reads the application-layer content: URLs, headers, parameters, and body data. It can block requests containing SQL injection payloads or XSS strings, which look perfectly normal to a network firewall passing traffic on port 443. Both are necessary. Neither substitutes for the other.
Can a WAF replace penetration testing?
No. A WAF is a runtime control that blocks malicious requests as they arrive. A penetration test is a periodic manual assessment that evaluates your application from an attacker's perspective, identifies vulnerabilities the WAF cannot address, and validates whether WAF configuration is working as intended. Penetration testing finds the business logic flaws, IDOR vulnerabilities, authentication weaknesses, and WAF bypass paths that your WAF will never block because it cannot understand them. A WAF that has never been tested against bypass methodology may be providing a false sense of protection.
Do I need a WAF if I do regular penetration testing?
Yes. A penetration test is a point-in-time assessment, typically annual or tied to major releases. Between tests, your application receives real traffic from real attackers. A WAF provides continuous runtime protection during that interval: blocking automated exploitation attempts and commodity scanning tools around the clock. Penetration testing tells you what vulnerabilities exist and validates your controls. The WAF provides runtime enforcement between assessments. Removing either creates a gap.
What WAF bypass techniques do penetration testers use?
Common techniques include double URL encoding, Unicode normalisation, HTTP parameter pollution, chunked transfer encoding, SQL comment insertion, case variation in keywords, and payload fragmentation across multiple requests. The appropriate technique depends on the WAF product, its rule configuration, and the specific vulnerability being tested. The goal is to determine whether an attacker could bypass the WAF in practice, and to identify which attack categories succeed against the current configuration.
Does a WAF stop zero-day attacks?
No. A WAF blocks attacks matching known signatures. Zero-day vulnerabilities have no signature until after public disclosure, and often not until a WAF vendor ships an updated rule. That gap can take days or weeks. The Capital One breach (2019) is a documented example: a WAF was active but the specific attack pattern was not covered in the deployed ruleset. Defence against zero-days requires secure application design and defence-in-depth, not WAF rules alone.
What is the OWASP Core Rule Set?
The OWASP Core Rule Set (CRS) is the standard open-source WAF ruleset maintained by the OWASP CRS Project. It is the default ruleset for ModSecurity and compatible WAFs, and it underpins many commercial WAF offerings. The CRS 4.x release uses an anomaly scoring model: each rule match adds to a score, and requests exceeding a threshold are blocked. It covers SQL injection, XSS, remote file inclusion, PHP injection, Java injection, and path traversal. It does not cover business logic, IDOR, or authentication flaws by design, because those require application-specific knowledge.