Web Application Firewalls: Protecting Your Customer-Facing Applications
Attackers follow the path of least resistance.
Network perimeters have become harder to breach directly, so the focus has shifted to the applications sitting on top of them. Customer-facing web applications present a large, accessible, and often inconsistently protected attack surface, and the statistics reflect that clearly.
The 2025 Verizon Data Breach Investigations Report recorded 1,701 web application incidents with 1,387 confirmed data compromises, every single one originating from external actors. Stolen credentials powered 88% of those web application breaches, with brute force attacks against basic web apps nearly tripling over the prior year. For organizations running customer-facing applications, the application layer is both the most exposed surface and the one that tends to receive the least direct security attention.
Web application firewalls exist specifically to address that gap, and understanding what they actually do and where the limits of the technology are is worth the investment for any technology leader responsible for customer-facing systems.
What a WAF Does That a Network Firewall Doesn't
A traditional firewall operates at the network and transport layers. It inspects IP addresses, ports, and protocols, making decisions about what traffic to allow or block based on network-level attributes. That level of inspection is necessary but not sufficient for protecting web applications, where the attack surface is the application logic itself rather than the network connection.
A web application firewall operates at Layer 7 of the OSI model, the application layer, defending against attacks such as SQL injection, cross-site scripting, and cookie poisoning. Unlike traditional firewalls that manage traffic at the network level, a WAF functions as a reverse proxy, inspecting incoming requests before they reach the application server.
That distinction matters in practice. A SQL injection attack arrives over a perfectly legitimate HTTP connection on port 443. A network firewall sees an encrypted HTTPS request and has no reason to block it. A WAF inspects the contents of that request and identifies that it contains a malicious payload attempting to manipulate the application's database queries. The threat exists at the application layer and can only be detected by a tool operating at that layer.
Injection attacks, including SQL injection and cross-site scripting, remain one of the most dangerous and consistently exploited vulnerability categories, continuing to surface in high-profile breaches more than two decades after OWASP first identified them as a top risk. The longevity of these attack types reflects how reliably organizations fail to address them at the code level, either through insufficient development practices or the practical difficulty of patching production applications quickly enough to stay ahead of disclosed vulnerabilities.
The Core Capabilities That Matter
WAFs vary considerably in sophistication, but the capabilities that separate adequate protection from genuinely effective protection tend to cluster around a few areas.
Virtual patching deserves particular attention for technology leadership evaluating WAF investments. A WAF can apply a protective rule within hours of a vulnerability disclosure, providing effective coverage during the window between disclosure and permanent code remediation. For organizations that run complex applications where patching cycles are constrained by QA and deployment requirements, that gap-filling capability has direct operational value.
Machine Learning and the False Positive Problem
Traditional signature-based WAFs present an operational challenge that has historically limited their effectiveness. WAF rules written against known attack patterns generate false positives, legitimate traffic that resembles malicious patterns and gets blocked. In a production environment protecting customer-facing applications, a high false positive rate means either accepting the security gaps created by loosening rules or accepting the customer experience degradation caused by blocking legitimate requests. Most organizations historically chose the former.
FortiWeb addresses this through a dual-layer machine learning approach: a first layer of traditional detection engines covering signatures, IP reputation, and protocol validation, followed by a machine learning detection engine that continuously models each specific application's normal behavior to identify anomalies, distinguishing genuine threats from legitimate traffic that simply looks unusual.
The practical difference is significant. A WAF that models each application's actual behavior can make detection decisions based on whether a request is anomalous relative to that specific application, rather than just checking it against a library of known attack signatures. FortiWeb achieved 92.39% security efficacy and 96.2% operational efficiency in the 2025 SecureIQLab independent testing, demonstrating high detection rates while minimizing false positives across both common and complex attack scenarios.
For organizations that have previously deployed WAFs and found them operationally difficult to maintain, a common experience with rule-based WAFs that require constant manual tuning as applications evolve, the machine learning approach substantially reduces the ongoing management burden.
API Security: The Gap Most WAFs Miss
Modern customer-facing applications rarely consist of a single web application. They are composed of APIs, interfaces that mobile applications call, that third-party integrations rely on, and that microservices use to communicate. Each of those API endpoints is a potential attack surface, and APIs present some attack vectors that traditional WAF rules do not adequately address.
Fortinet's research found that 30% of organizations experienced credential theft attempts through their applications, a category of attack that targets the authentication and session management functions that APIs heavily rely on.
FortiWeb's API discovery and protection uses machine learning to automatically identify API endpoints by continuously evaluating application traffic, then applies protection against malicious payloads targeting those endpoints. For organizations whose customer-facing architecture has expanded to include mobile applications, partner integrations, and microservices-based backends, that automatic discovery capability addresses a coverage gap that manually configured WAF rules tend to leave open. Not because the rules are wrong, but because the API inventory they are meant to protect is rarely fully documented or consistently updated.
Deployment Options and Integration with the Security Stack
WAFs are available in multiple deployment models, and the right choice depends on where the applications being protected actually run. Hardware appliances make sense for organizations protecting applications in on-premises data centers. Virtual appliances provide the same capabilities in private cloud or virtualized environments. Cloud WAF-as-a-Service is the right model for applications deployed in public cloud environments, where a software appliance would add infrastructure overhead and deployment complexity that undercuts the cloud's operational advantages.
FortiWeb Cloud WAF-as-a-Service delivers comprehensive protection across AWS, Azure, Google Cloud, and Oracle Cloud deployments, with pay-as-you-go pricing that allows organizations to right-size protection to their actual application footprint rather than provisioning excess capacity.
For organizations already running Fortinet infrastructure, FortiWeb integrates directly with FortiGate next-generation firewalls and FortiSandbox for coordinated threat intelligence sharing. A threat detected by one product updates the protections applied by others without manual intervention or separate management workflows. Security teams spend less time correlating events across disconnected tools and more time responding to the threats that matter.
The Compliance Dimension
For many organizations, the initial WAF deployment is compliance-driven. PCI DSS requires WAF protection for any application that processes, stores, or transmits cardholder data, and that requirement has been a primary driver of WAF adoption in retail, financial services, and healthcare. PCI DSS compliance was historically the main reason most organizations deployed WAFs, but many organizations now recognize that unprotected web applications represent the most accessible entry point for attackers, even those with limited sophistication.
The compliance requirement is a useful forcing function, but it tends to produce minimum-viable WAF deployments rather than configurations optimized for actual risk reduction. Organizations that deployed WAFs primarily to satisfy PCI requirements frequently find, on review, that rule sets have not been updated, that API endpoints added after the initial deployment are not covered, and that the false positive rate has led to rule loosening that creates meaningful gaps. Treating WAF maintenance as an ongoing operational discipline rather than a one-time compliance checkbox is where the actual security value comes from.
Connecting the Security Stack
A WAF addresses the application layer, but it operates most effectively as part of an integrated security architecture rather than a standalone control. Network-level perimeter security handles threats before they reach the application. ZTNA governs who can access internal applications and under what conditions. The WAF inspects the contents of legitimate, authenticated requests to ensure they do not contain malicious payloads targeting application vulnerabilities.
For organizations that have worked through the perimeter security and remote access layers of their security architecture, the WAF represents the next logical investment, addressing the attack surface that those controls, by design, do not reach.
For more on the foundational security stack that a WAF sits within, our piece on next-gen firewalls covers the perimeter security layer in detail. If your organization is working through remote access security alongside web application protection, our piece on Zero Trust Network Access addresses how ZTNA and WAF capabilities complement each other in a layered security model.
Evaluating your web application security posture or considering a FortiWeb deployment? Talk to the Tricension team about where your customer-facing applications carry the most exposure.
.webp){kind=logo}