A web application can be perfectly reachable, properly patched, and sitting behind a well-configured network firewall and still be vulnerable to a malicious request.
That is because not every attack looks like an obvious intrusion. Some arrive as ordinary web traffic, hiding the attack inside a form field, URL parameter, API request, or login attempt. This is where a Web Application Firewall (WAF) comes in.
What is A Web Application Firewall (WAF)?
WAF is a security control that filters, monitors, and blocks malicious HTTP and HTTPS traffic between a web application and the internet, sitting in front of the application to inspect every request before it reaches the server. It operates at the application layer, examining the actual content of a request rather than just the source IP address or port a traditional firewall checks.
Web applications face a different threat model than networks. An attacker does not need to breach a firewall or guess a password to exploit a flaw in how an application handles user input; a single malformed request can trigger SQL injection, cross-site scripting, or a dozen other attack types that a network firewall was never built to recognize. A WAF exists to close that specific gap.
What Does a WAF Protect Against?
A WAF defends against the categories of attack that exploit how a web application processes input, rather than weaknesses in the network carrying that input.
SQL injection manipulates a database query by inserting malicious code into a form field or URL parameter, potentially exposing or altering an entire database. Cross-site scripting (XSS) injects malicious scripts into pages viewed by other users, often to steal session cookies or credentials. File inclusion vulnerabilities let an attacker force an application to load and execute a file it should never touch. Cross-site request forgery tricks an authenticated user’s browser into submitting a request the user never intended to send. Many of these categories appear year after year in the OWASP Top Ten, the industry’s most widely referenced ranking of web application risks, which is part of why WAF rulesets are commonly built around it.
A WAF also absorbs a meaningful share of application-layer denial-of-service traffic and credential-stuffing attempts before they reach the application itself.
How Is a WAF Different From a Traditional Network Firewall?
A traditional network firewall makes decisions based on IP address, port, and protocol: it decides whether traffic is allowed to reach a server at all. It has no visibility into what a legitimate-looking HTTPS request contains once that traffic is permitted through.
A WAF operates one layer up, inspecting the full content of each HTTP request, headers, cookies, form fields, and the request body, after the network firewall has already let it pass. This is why a network firewall and a WAF are complementary rather than interchangeable. An attacker sending a SQL injection payload over port 443, the same port used for ordinary web browsing, sails straight past a correctly configured network firewall. A WAF is what reads the request itself and recognizes the attack pattern hidden inside it.
How Does a WAF Decide What to Block?
WAFs use one of two underlying models, or a combination of both, to decide what traffic to allow.
A negative security model, also called a blocklist approach, defines known attack signatures and blocks any request matching one, like how traditional antivirus software works. It is easier to deploy and generates fewer false positives on legitimate traffic, but it can only catch attack patterns someone has already identified and written a rule for. A positive security model, or allowlist approach, defines exactly what legitimate traffic should look like for a given application and blocks everything that deviates from it. This catches novel attacks a signature-based rule would miss, but it takes considerably more tuning to build and maintain without blocking valid users by mistake.
Most modern WAFs combine both models, using signature-based rules for known attack patterns and behavioral or machine learning-based detection to flag traffic that looks anomalous even without a matching signature.
What Are the WAF Deployment Modes?
Organizations deploy a WAF in one of three general forms.
- A network-based WAF runs on dedicated hardware installed on-premises, offering low latency and full control but requiring capital investment and ongoing maintenance.
- A host-based WAF integrates directly into the application’s own software, which gives it deep visibility into application behavior at the cost of consuming server resources and needing separate configuration for every application it protects.
- A cloud-based WAF, delivered as a service in front of the application, is the fastest to deploy and the easiest to update with new rules across every protected application at once, which is why it has become the default choice for most organizations, particularly those running applications across multiple environments as part of a broader cloud security strategy.
Why Does PCI DSS Require a WAF Now?
Regulatory pressure has turned what was once a best practice into a hard requirement for a large share of businesses. PCI DSS Requirement 6.4.2 requires organizations handling payment card data to deploy an automated technical solution in front of every public-facing web application that continually detects and prevents web-based attacks, replacing the earlier version of the standard that allowed periodic vulnerability scans as an alternative.
According to the PCI Security Standards Council, a properly configured WAF is the most direct way organizations satisfy this requirement, since it operates continuously rather than checking for vulnerabilities on a fixed schedule.
For any organization processing, storing, or transmitting cardholder data through a public website, a WAF is no longer optional. It is a documented compliance control an assessor will look for by name.
What Are the Limitations of a WAF?
A WAF is not a substitute for secure code. It blocks known and suspicious attack patterns from reaching an application, but it does not fix the underlying vulnerability the attack was trying to exploit, which means a misconfigured or poorly tuned WAF can create a false sense of security while the real flaw stays in production. Tuning is a real, ongoing effort: a WAF set to block aggressively can reject legitimate traffic and break application functionality, while one tuned too loosely lets attacks through unnoticed.
Coverage has also expanded faster than the term itself. Modern applications lean heavily on APIs and bot-driven traffic that a classic, request-inspection WAF was not originally built to handle, which is why Gartner now frames the category as Web Application and API Protection, combining WAF, DDoS mitigation, bot management, and API security into a single platform rather than treating them as separate tools.
How Should CISOs Choose and Tune a WAF?
Selecting and running a WAF well takes more than turning on default rules.
- Start in monitoring mode: Run new rules in detection-only mode before switching to active blocking, so legitimate traffic patterns surface before anything gets rejected.
- Pair it with secure development: A WAF buys time to fix a vulnerability; it does not replace fixing it. Findings from DevSecOps practices and application testing should still drive remediation.
- Extend coverage to APIs and bots: Confirm the platform inspects API traffic and distinguishes automated bot activity from real users, not just standard HTML form submissions.
- Layer it with DDoS protection: A WAF handles application-layer attacks; pairing it with dedicated DDoS mitigation covers volumetric attacks a WAF alone was not designed to absorb.
- Treat it as part of Zero Trust: A WAF enforces policy at the edge of the application, one layer within a broader Zero Trust approach rather than a perimeter that replaces it.
Review and retune rules on a regular cadence. An application that changes weekly needs a WAF policy that keeps pace with it.
Key Takeaway
A WAF will not make an insecure application secure, but it closes the gap between when a vulnerability is discovered and when it gets fixed, and it stops entire categories of attack a network firewall was never designed to see. For any organization running a public-facing application, especially one handling payment or personal data, it has moved from a nice-to-have to a documented, expected control.
| Talk to Ampcus Cyber’s Web Application Firewall team to deploy and tune a WAF that satisfies PCI DSS Requirement 6.4.2 without breaking your application’s legitimate traffic. |
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
