A Web Application Firewall sits between the internet and your web application, reading every HTTP and HTTPS request before it reaches your code. What it does with those requests depends entirely on how it is configured, what detection models it uses, and how well it has been tuned to your specific application. Getting those things right is where most WAF deployments succeed or fail.
Most explanations of WAFs focus on what they protect against: SQL injection, cross-site scripting, the OWASP Top 10. That framing is accurate but incomplete. It describes the output of a WAF rather than the mechanism. Understanding how a WAF actually makes its allow-or-block decisions, the fundamental tradeoff between false positives and false negatives, and the difference between the negative and positive security models is more useful for anyone evaluating, deploying, or troubleshooting a WAF than a list of attack categories.
This guide covers the WAF inspection mechanism, the two core security models and their operational implications, deployment architectures and their relationship to SSL/TLS, the attacks WAFs handle well and those they handle poorly, and what WAFs do not do despite sometimes being sold as if they do.
How a WAF Sees and Inspects Traffic
A traditional network firewall operates at the transport layer. It sees IP addresses, ports, and protocols. It can decide whether traffic from a certain IP to a certain port is permitted or denied, but it cannot read the content of that traffic. It has no awareness of HTTP, HTML, JavaScript, SQL, or any application-level data.
A WAF operates at the application layer (Layer 7 of the OSI model). It terminates the HTTP or HTTPS connection, parses the full request, and evaluates the content against its rule set before deciding whether to forward the request to the origin server, block it, or challenge the client. The request content it can inspect includes the URL and query string parameters, request headers including cookies, the request body for POST data and file uploads, the HTTP method and HTTP version, and the response body if the WAF also inspects outbound traffic.
For HTTPS sites, a WAF must decrypt the traffic to inspect it. This means the WAF handles TLS termination: it presents your SSL certificate to the client, establishes the encrypted session, decrypts the traffic, inspects it, and if it determines the traffic is legitimate, re-encrypts it before forwarding to the origin server. The origin server then receives either HTTPS traffic (if the WAF establishes a new TLS session to the origin) or HTTP traffic on a private internal network depending on the deployment architecture.
The WAF’s TLS handling is relevant to SSL certificate management. When a WAF terminates TLS, the SSL certificate presented to visitors is installed on the WAF, not the origin server. Certificate renewal must happen on the WAF layer. If the WAF forwards traffic to the origin over HTTPS, the origin also needs a valid certificate, but it may be a private certificate trusted only by the WAF rather than a publicly trusted one, since clients never see it directly.
What a WAF Inspects in Each Request
Every HTTP request the WAF receives is parsed into its component parts before rule evaluation begins. The depth of inspection determines both the WAF’s detection capability and its performance overhead.
| Request Component | What the WAF Examines | Example Threats Detected |
| URL path | The resource being requested; path traversal patterns | Directory traversal (../../etc/passwd), path manipulation |
| Query string parameters | Name-value pairs in the URL after ? | SQL injection (id=1′ OR 1=1), XSS (?q=<script>), LFI (?file=../../../../etc/passwd) |
| Request headers | Cookie, Referer, User-Agent, X-Forwarded-For, and custom headers | Cookie injection, header injection, bot identification via User-Agent |
| Request body | POST data, JSON, XML, multipart form data | SQL injection in form fields, XXE in XML payloads, malicious file uploads |
| HTTP method | GET, POST, PUT, DELETE, PATCH, OPTIONS, and non-standard methods | Non-standard method exploitation, HTTP verb tampering |
| Response body | Outbound HTML, JSON, and file content (if response inspection is enabled) | Data loss prevention: blocking responses containing credit card numbers, SSNs |
| Request rate and pattern | Frequency and sequence of requests from an IP or session | Rate-limit evasion, brute force, credential stuffing, scraping |
The Two Detection Models: Negative Security and Positive Security
Every WAF rule and every WAF configuration decision ultimately falls into one of two security models. The choice between them, or the combination of them, determines how the WAF behaves against both attacks and legitimate traffic. Most articles mention these models in a sentence or two. The operational implications are worth more space.
The negative security model: block what is known bad
A negative security model works by defining patterns of malicious content and blocking any request that matches those patterns. It is a blocklist approach: everything is allowed by default, and specific bad things are denied. The ModSecurity Core Rule Set (CRS), used by Apache ModSecurity and Nginx ModSecurity, is the most widely deployed implementation of a negative security model. It contains thousands of signatures matching known attack patterns for SQL injection, XSS, command injection, path traversal, and dozens of other attack categories.
The operational advantage of the negative security model is that it can be deployed quickly on any application without needing to understand the application’s specific behavior. You install the rule set, enable it in detection mode to observe what it would block, tune out false positives for your application’s legitimate traffic, and then switch to blocking mode. The initial deployment is fast because you do not need to profile the application first.
The limitation is the inverse of that advantage: the negative security model only knows what it has been taught. A zero-day vulnerability with an attack pattern not yet represented in the rule set passes through. An attacker who understands the rule set can craft payloads that achieve the same malicious effect through patterns the rules do not match. The rule set must be continuously updated as new attack techniques emerge, creating an ongoing maintenance dependency.
The positive security model: allow only what is known good
A positive security model works by defining what legitimate requests look like and blocking everything that does not match. It is an allowlist approach: everything is denied by default, and specific legitimate patterns are permitted. For a login endpoint, a positive security model might specify: the endpoint accepts POST requests, has two form fields (username and password), the username field accepts alphanumeric characters and underscores up to 50 characters, and the password field accepts any printable characters up to 128 characters. Any request to the login endpoint that does not match this specification is blocked.
The operational advantage is comprehensive: a properly configured positive security model stops all injection attacks, including novel zero-days, because the attack payload does not match the expected parameter format. An attacker cannot inject SQL into a username field that the WAF only allows alphanumeric characters in.
The operational cost is significant. Building a positive security model requires deep understanding of every endpoint in the application, every expected input format, and every legitimate variation in request structure. API-heavy applications with dozens of endpoints and complex parameter structures require extensive documentation and rule creation effort. Any legitimate application change (adding a new form field, changing a parameter name, extending a field’s maximum length) requires a corresponding WAF rule update or the legitimate change will be blocked. This tight coupling between WAF configuration and application behavior is what makes positive security models expensive to maintain.
Production WAFs almost always use a hybrid of both models: a negative security model as the default, catching known attack patterns across all endpoints, combined with positive security rules for the highest-risk endpoints where the application’s behavior is well-defined and stable, such as authentication, payment processing, and API endpoints with fixed schemas. This combination provides broad baseline protection without the maintenance burden of documenting every endpoint, while adding precise protection for the routes most likely to be targeted.
The False Positive Problem: Why WAF Tuning Is Non-Negotiable
A false positive is a legitimate request that a WAF incorrectly blocks. The term understates the operational damage: a false positive is your customer’s checkout failing silently, a search query returning a block page instead of results, a password containing special characters being rejected, or an internal tool that relies on URL parameters being blocked for a security team member trying to do their job.
False positives are inevitable with any negative security model deployed out of the box. The reason is that attack signatures are pattern-based, and legitimate application content sometimes matches those patterns. A product description that mentions SQL commands for technical documentation, a username that contains a less-than sign, a URL parameter that contains what looks like a path traversal sequence but is actually a relative link — all of these can trigger WAF rules designed to detect attacks.
The response to false positives determines whether a WAF is a security tool or a reliability liability. Three outcomes are possible. The WAF is deployed in detection-only mode permanently, logging what it would block but never blocking — this provides visibility but no protection. The WAF is deployed in blocking mode with no tuning — this blocks attacks but also blocks legitimate users, generating support tickets and revenue loss. The WAF is deployed in detection mode, tuned over time against real production traffic, false positives are identified and addressed, and blocking mode is enabled only after confidence is established. The third approach is the only operational one.
A WAF deployed in full blocking mode from day one on a production application without a tuning period is a production incident waiting to happen. A single rule that fires on a legitimate request pattern your application uses can break a checkout flow, disable file uploads, or block an API endpoint. The standard practice is to deploy in detection mode first, analyze the logs for false positives with real traffic, create exceptions for confirmed legitimate traffic that matches rules, and then progressively enable blocking.
Attacks WAFs Protect Against Well
WAFs are highly effective against a specific category of threats: known attack techniques against predictable application vulnerabilities. For these, the combination of signature coverage and rule set maturity provides reliable protection.
SQL injection
SQL injection occurs when user-supplied input is incorporated into a database query without proper sanitization. The attacker manipulates the query to extract data, modify records, or escalate privileges. WAF detection for SQL injection is mature: the OWASP Core Rule Set contains over 150 rules for SQL injection patterns, covering MySQL, MSSQL, Oracle, PostgreSQL, and SQLite syntax variations. A well-tuned WAF with up-to-date rules catches the vast majority of SQL injection attempts.
Cross-site scripting (XSS)
XSS attacks inject malicious JavaScript into a web page that executes in other users’ browsers. Reflected XSS injects through URL parameters; stored XSS injects through form submissions stored and displayed later. WAFs detect XSS by identifying HTML tags, JavaScript event handlers, and encoding variations used to bypass basic filters in request parameters and bodies. Detection quality varies: simple XSS attempts are caught reliably; heavily obfuscated attacks using Unicode encoding, CSS injection, or DOM-based techniques may require more specific rules.
Known vulnerability exploitation
When a vulnerability in a popular CMS plugin, web framework, or web server component is discovered and published, security researchers and attackers both analyze the exploit pattern. WAF vendors typically release signature updates within hours or days of a vulnerability publication. This virtual patching capability is one of the most operationally valuable WAF features: a WAF with an up-to-date rule set can block exploitation attempts against a known vulnerability before the underlying software is patched, buying time for proper remediation.
Automated attack traffic
Credential stuffing attacks use lists of breached username-password combinations to test access to accounts. Scraping bots extract content systematically. Scanner tools run automated vulnerability probes against every endpoint. WAFs with rate limiting and behavioral analysis detect and block this traffic by identifying automated patterns: requests arriving too quickly for a human, requests following no navigation pattern, scanning requests to non-existent endpoints, and user agent strings associated with known attack tools.
What WAFs Do Not Protect Against
The marketing around WAFs sometimes implies more comprehensive protection than the technology provides. Being clear about the boundaries prevents treating a WAF as a complete security solution when it is one layer in a larger defense.
Logic flaws and authorization failures
Application logic vulnerabilities are not detectable by inspecting individual requests in isolation. If an e-commerce site allows any user to view any order by changing the order ID in the URL, the individual request looks legitimate to a WAF: it is a valid GET request with a valid order ID format from an authenticated session. The vulnerability is in the application’s failure to verify that the requesting user owns that order. A WAF cannot know what the application’s intended authorization rules are. Broken access control, Insecure Direct Object References, and business logic flaws require application-level fixes.
Attacks targeting authenticated sessions
Once a user is authenticated, requests carry valid session tokens that identify them as authorized. A WAF in positive mode might inspect the structure of requests, but if the request structure is legitimate and the session token is valid, an attacker who has compromised a session (through session fixation, token theft, or prediction) can make requests that are indistinguishable from the legitimate user’s requests. WAFs do not manage authentication session security.
Server-side vulnerabilities in application code
A WAF inspects inbound requests but cannot protect against vulnerabilities in the application’s own logic, its dependencies, or its configuration that do not require malicious input to exploit. Misconfigured cloud storage buckets, exposed debug endpoints, default credentials on admin interfaces, and unprotected API endpoints that require only a valid request format are not WAF problems; they are application and infrastructure security problems.
Supply chain and dependency attacks
If malicious code is introduced into a third-party library the application depends on, or if a JavaScript CDN delivers a compromised script, the attack originates within the application’s own trusted code path. A WAF positioned in front of the application sees only inbound requests from users, not the internal execution of the application’s dependencies. Attacks like the 2021 log4shell vulnerability or Magecart card-skimming attacks injected through compromised third-party scripts are beyond the WAF’s inspection scope.
A WAF is not a substitute for secure application development practices. Virtual patching through WAF rules is a useful interim measure while vulnerabilities are fixed at the code level, but it should never become a permanent alternative to fixing the underlying vulnerability. WAF rules can be bypassed by attackers who understand them. The only reliable fix for an application vulnerability is fixing the application.
Deployment Architectures and Operational Trade-offs
WAFs are deployed in three primary architectural models. The choice affects performance, SSL certificate management, deployment complexity, and the depth of inspection available.
| Deployment Model | How Traffic Flows | SSL Certificate Location | Advantages | Limitations |
| Cloud WAF / CDN WAF (Cloudflare, AWS WAF, Imperva) | DNS points to the cloud WAF, which inspects traffic and forwards to origin. Origin receives traffic from the WAF’s IP range. | Certificate managed on the cloud WAF layer. Origin may use a private cert. | No hardware to manage. Automatic rule updates. Global network for DDoS mitigation. Rapid deployment. | Dependent on the provider’s availability and pricing. Limited custom rule complexity. Traffic to origin is visible to the WAF provider. |
| Reverse proxy WAF (on-premises or cloud VM, e.g., ModSecurity with Nginx) | WAF is deployed as a reverse proxy. All traffic terminates at the WAF, is inspected, then forwarded to the origin. | Certificate installed on the WAF proxy. Origin can use HTTP on private network. | Full control over rules and configuration. Deep inspection. Can integrate with internal authentication. | Requires operational management. Rule updates are manual or semi-manual. Can become a single point of failure. |
| Host-based WAF (agent on the application server) | WAF agent runs on the same server as the application, inspecting requests before they reach the application code. | Handled by the web server as normal. WAF is not in the TLS path. | Can inspect post-decryption content, including header normalizations. No separate infrastructure. | Consumes server resources. Must be deployed and maintained on every server. Harder to manage at scale. |
Cloud WAFs have become the dominant deployment model for most organizations because they require no infrastructure management and provide DDoS mitigation alongside application-layer inspection. Cloudflare’s WAF, AWS WAF, and Azure Application Gateway WAF all sit in front of the origin server and handle TLS termination. Organizations using these services manage their SSL certificates through the CDN or cloud provider’s certificate management interface rather than directly on the origin server.
WAFs and the OWASP Top 10
The OWASP Top 10 is a widely cited list of the most critical web application security risks, updated every four years based on data from security assessments worldwide. WAF vendors routinely state that their product protects against the OWASP Top 10, which is both true and requires qualification. The level of WAF protection varies significantly across the ten categories.
| OWASP Category | WAF Effectiveness | Why |
| Injection (SQL, command, LDAP) | High | Well-defined attack patterns; mature signature sets |
| Broken Access Control | Low | Requires understanding application authorization logic, not request patterns |
| Cryptographic Failures | None | Server-side configuration issue unrelated to request inspection |
| Insecure Design | None | Architectural problem in application logic, not detectable by request inspection |
| Security Misconfiguration | Partial | WAF can block exploitation of some misconfigurations; cannot detect the misconfiguration itself |
| Vulnerable Components | Moderate | Virtual patching can block known exploits; does not address the vulnerable code |
| Authentication Failures | Moderate | Rate limiting and credential stuffing detection help; cannot fix broken auth design |
| Software and Data Integrity Failures | Low to None | Supply chain attacks and deserialization beyond typical WAF scope |
| Logging and Monitoring Failures | None | WAFs provide log data; cannot compensate for absent application logging |
| Server-Side Request Forgery (SSRF) | Moderate | Some SSRF patterns detectable in request parameters; internal SSRF harder to detect |
| Cross-Site Scripting (XSS) | High | Well-defined attack patterns in request parameters; some encoding evasions require tuning |
Frequently Asked Questions
What is a Web Application Firewall and how does it work?
A Web Application Firewall (WAF) is a security control that inspects HTTP and HTTPS traffic between the internet and a web application. It sits in front of the application as a reverse proxy, decrypts HTTPS traffic, parses each request into its components (URL, parameters, headers, body), and evaluates those components against a set of security rules. Requests that match attack signatures or violate security policies are blocked or challenged. Requests that pass inspection are forwarded to the origin server. WAFs operate at the application layer (Layer 7) and are therefore able to inspect content that network-layer firewalls cannot see.
What is the difference between a WAF and a firewall?
A traditional network firewall controls traffic based on IP addresses, ports, and protocols. It can block traffic from certain networks or to certain ports but cannot read application-level content. A WAF inspects the content of HTTP and HTTPS requests: URL parameters, headers, cookies, and request bodies. It understands web application attack patterns like SQL injection and cross-site scripting that are invisible to a network firewall. The two are complementary: a network firewall controls network-level access, a WAF controls application-level access. Most production security architectures use both.
What is a false positive in WAF context?
A WAF false positive is a legitimate request that the WAF incorrectly classifies as an attack and blocks. For example, a search query containing the word select might trigger a SQL injection rule, or a product description containing HTML-like text might trigger an XSS rule. False positives block legitimate users from using the application and require tuning to address. The false positive rate is one of the most operationally significant WAF characteristics: a WAF with a high false positive rate will either be turned off, put into detection-only mode, or generate constant support escalations. Reducing false positives through rule tuning and exception configuration is an ongoing WAF operational task.
What is the difference between negative and positive WAF security models?
A negative security model blocks known bad patterns while allowing everything else by default. It is a blocklist approach: SQL injection signatures, XSS patterns, and other known attack indicators are defined as rules, and any request matching them is blocked. A positive security model allows only known good patterns while blocking everything else by default. It is an allowlist approach: the WAF is configured to accept only the specific parameter formats, request structures, and input values the application legitimately uses. Negative models are faster to deploy but miss unknown attacks. Positive models provide comprehensive protection but require deep application knowledge to configure. Most production WAFs use a hybrid of both.
Does a WAF replace the need for secure application development?
No. A WAF is a defense-in-depth control, not a replacement for secure code. It can block many known attack patterns and provide virtual patching while underlying vulnerabilities are fixed, but it cannot fix application logic flaws, authorization failures, or design vulnerabilities. Attackers who understand a WAF’s rule set can craft bypass techniques. Security researchers regularly demonstrate WAF bypass methods for even well-configured commercial WAFs. The correct security posture is secure application development as the primary defense, with a WAF as an additional layer that increases attacker cost and provides logging and alerting for attack detection.
How does a WAF relate to SSL certificates?
A WAF that operates as a reverse proxy terminates TLS connections, meaning it handles the SSL handshake and certificate verification on behalf of the origin server. Visitors’ browsers establish a TLS connection with the WAF, and the WAF presents the site’s SSL certificate. For this to work, the SSL certificate must be installed on the WAF layer, not the origin server (or both, if the WAF also establishes TLS to the origin). When using a cloud WAF like Cloudflare, the SSL certificate is managed through the cloud provider’s interface. Certificate renewal must happen on the WAF, because that is what clients connect to. If the WAF’s certificate expires or is misconfigured, visitors see SSL errors even if the origin server has a valid certificate.
What is virtual patching and when is it appropriate?
Virtual patching is the creation of a WAF rule that blocks exploitation of a known vulnerability without modifying the vulnerable application code. When a vulnerability is disclosed in a web framework or plugin (a critical WordPress plugin vulnerability, for example), a WAF rule can be deployed within hours to block requests matching the known exploit pattern, while the proper code fix is developed, tested, and deployed through the normal change management process. Virtual patching is appropriate as a temporary measure bridging the gap between vulnerability disclosure and code-level remediation. It is not appropriate as a permanent alternative to fixing the vulnerable code, because WAF rules can be bypassed and the underlying vulnerability remains exploitable through any bypass that works against the rule.
