- A WAF protects the application layer by filtering HTTP/HTTPS traffic against threats such as injections, XSS, or brute force.
- Always-on detections combine rules, signatures, behavioral analysis, and continuous updates.
- There are different WAF and deployment models, which must be integrated with NGFW, IPS, SIEM and other security layers.
- The evolution to WAAP/WAAS adds specific protection for APIs, automatic discovery, and advanced bot and DDoS mitigation.
Web security is no longer just about installing antivirus software and hoping for the best. Today, web applications and APIs are at the heart of almost every business , making them prime targets for attacks. From online stores to digital banking and SaaS platforms, everything runs over HTTP and HTTPS—which is precisely where web application firewalls come into play.
A modern WAF does more than just filter traffic: it offers always-on detection in the web application firewall , adjusts its rules in real time, integrates with other layers of defense, and helps comply with regulations such as PCI DSS or GDPR. The key is to fully understand what it does, how it works, what models exist, and how to implement it without compromising performance or user experience.
What is a WAF and why is it so critical today?
A web application firewall (WAF) is a specialized security mechanism at layer 7 of the OSI model, designed to monitor, filter, and block HTTP and HTTPS traffic entering and leaving a web application or API. Unlike a traditional firewall, which protects the overall network (layers 3 and 4), a WAF sits between the client and the application and understands the context of web requests.
Its primary mission is to stop attacks that exploit vulnerabilities within the application itself : SQL injections, cross-site scripting (XSS), cross-site request forgery (CSRF), authentication abuse, brute-force attempts, exploitation of cryptographic or access control flaws, etc. Many of these threats are included in the famous OWASP Top 10, which remains the industry benchmark decades later.
This type of firewall can be offered as a physical device, software installed on servers, or a cloud service . Regardless of the model, the idea is the same: to inspect each HTTP/HTTPS request, compare it against a set of security policies, and decide in milliseconds whether to allow, block, or challenge the client (for example, with a captcha or a JavaScript challenge).
In an environment where applications are released quickly, with open-source components and continuous deployments, it's common for vulnerabilities to be present in production before they can be patched . That's where a WAF acts as an "airbag": it doesn't fix the code, but it can prevent attacks from exploiting it.
Main threats that a web application firewall blocks
A well-configured WAF can mitigate a wide range of attacks against applications and APIs . Some of the most common are:
- SQL Injection (SQLi)The attacker attempts to inject SQL commands into forms or parameters to read, modify, or delete data from the database.
- Cross-Site Scripting (XSS)This involves injecting malicious scripts into web pages to execute code in other users' browsers.
- Cross-Site Request Forgery (CSRF)The user is tricked into sending unwanted requests to an application where they are already logged in.
- Brute force attacks and credential stuffingPasswords or username/password combinations are tested until they are successful, usually in a massive and automated way.
- Buffer overflows and exploitation of server vulnerabilities: anomalous input patterns that seek to break the application's logic or memory.
- Application-level DDoS: flood specific URLs or endpoints with requests to exhaust application resources.
In addition, modern WAFs include capabilities to detect and stop malicious bot traffic (aggressive scraping, automated logins, bulk ticket buying, etc.) using techniques such as JavaScript verification, CAPTCHA, behavioral analysis, or device identification.
How always-on detection works in a WAF
The internal workings of a WAF are based on a deep HTTP/HTTPS traffic inspection engine and a set of policies or rules. Each request is analyzed at several levels to determine its destination:
On one hand, there are predefined rules , often based on standard sets such as the OWASP ModSecurity Core Rule Set or proprietary equivalents. These rules cover known attack signatures (typical patterns of SQL injection, XSS, path traversal, etc.).
On the other hand, always-on detection relies on more advanced analysis methods :
- Regular expressions to locate suspicious patterns within parameters, headers, bodies, and paths.
- Risk scoring models that assign a “hazard score” by combining multiple signals from each request.
- SmartParse of complex structures (JSON, XML, encoded payloads) to identify attacks that are disguised among legitimate data.
- Behavior analysis and historical traffic correlation to differentiate normal behavior from more subtle attack patterns.
With all this, the WAF can apply policies in real time: allowing, blocking, logging, or challenging a request . Furthermore, it records events in detailed logs that can then be sent to a SIEM or SOAR platform for correlation, auditing, and automated response.
A key point is that detections are not static. An effective WAF has constant updates to rules and signatures to adapt to new vulnerabilities and evasion techniques, and many incorporate machine learning and cloud-based threat intelligence to refine detection without constant manual intervention.
Security models: blacklist, whitelist, and hybrid
The behavior of the application firewall can be defined according to three main security approaches:
- Negative security model (blacklist)Requests are allowed by default, except those that match signatures or patterns categorized as malicious.
- Positive security model (whitelist)Everything that is not explicitly allowed is blocked; only requests that meet a very specific profile of "good traffic" are allowed through.
- Hybrid modelBoth approaches are combined, applying whitelists to critical operations and blacklists to the rest of the traffic.
Whitelisting is generally more secure but also more demanding to configure , as it requires a thorough understanding of what constitutes legitimate traffic. Blacklisting is simpler initially, but it can leave gaps for zero-day attacks or novel techniques. Therefore, many modern WAFs opt for a hybrid approach, adjustable per application or endpoint.
Types of WAFs according to their deployment
Depending on where and how they are installed, we can distinguish several types of web application firewalls, each with its pros and cons in terms of cost, control, visibility, and performance :
- Network-based WAFs (hardware): physical devices that are placed in the network infrastructure, between the Internet and application servers.
- Host-based or software-based WAFsThey are installed directly in the servers where the application runs, or as a module integrated into the app's own stack.
- cloud-based WAFs: offered as a service by a cloud or edge/CDN provider, they are typically configured by changing DNS or proxy settings.
- Hybrid deploymentsThey combine local WAFs (on-premises or host) with cloud-based WAFs to cover mixed, legacy, and cloud-native environments simultaneously.
Network devices offer low latency and extensive local control , but require investment in hardware and maintenance. Host WAFs provide granular visibility into the application, although they consume server resources and demand more management. Cloud services stand out for their scalability, rapid deployment, and ease of maintenance, although they sacrifice some internal control and, in some cases, the full context of all threats.
WAF versus other security systems: NGFW, IPS and traditional firewalls
It's common to confuse the role of a WAF with other security devices. Each one has its place in the architecture:
A traditional firewall defines the perimeter between the internal and external network, controlling ports, IP addresses, and protocols at a low level. It doesn't understand the logic of web applications, nor the content of forms or URLs.
A next-generation firewall (NGFW) extends this classic model by adding deep packet inspection, user and application control, antivirus, antimalware, and threat intelligence integration. Some NGFWs include WAF capabilities, but their focus remains primarily on the network, whereas a WAF is entirely focused on the application layer.
An intrusion prevention system (IPS) , on the other hand, analyzes all network traffic, across all protocols, to detect generic attack patterns. It typically relies on signatures and rules that are less contextual than a web application fable (WAF), and doesn't always delve as deeply into HTTP semantics or the application's business logic.
In practice, a robust architecture combines NGFW, IPS, and WAF , each specialized in its layer, feeding a central SIEM that correlates events, generates alerts, and enables a coordinated response, and connecting them with security tools to automate management.
Ways to deploy a WAF in the application architecture
In addition to the type of solution, you need to decide how the WAF is integrated into the application's traffic flow . The most common approaches are:
- Transparent bridgeThe WAF is located online, linked to the same ports as the application, without clients or servers explicitly "seeing" it.
- Transparent reverse proxyThe applications are aware of the WAF, but to the client it appears as if they are talking directly to the app.
- Explicit reverse proxyClients know they are connecting to a proxy, which in turn forwards requests to internal servers.
Bridge mode is usually the easiest to implement because it requires fewer configuration changes, but it offers less isolation between the app and the firewall . Different reverse proxy flavors provide better application isolation, facilitate TLS offloading, allow inspection of encrypted traffic, and offer more flexibility in applying advanced rules or load balancing logic.
Key advantages of using a web application firewall
Adopting a well-tuned WAF offers clear benefits at both the technical and business levels. Among the most relevant are:
- Advanced protection against application-specific attackswhich a network firewall or a simple IPS could not block with the same precision.
- Reducing the risk of data breaches and service outagesavoiding direct costs (stoppages, rescues, fines) and indirect costs (reputational damage, loss of trust).
- Assistance with regulatory complianceespecially in requirements such as PCI DSS, which require protection of Internet-oriented applications and evidence of threat monitoring and blocking.
- Scalability and flexibilityespecially in cloud and edge models, which allow for absorbing traffic spikes and variable loads without redesigning the entire infrastructure.
Many professional hosting providers offer a Web Application Forum (WAF) integrated into their platform. This simplifies the process, providing a website or application with automatic mitigation against injection, cross-site scripting (XSS), basic DDoS attacks, and authentication abuse right from the start, without requiring the team to create complex rules from scratch.
Real challenges when implementing a WAF and how to deal with them
Just because a WAF is powerful doesn't mean everything will be smooth sailing. There are a number of challenges to keep in mind so that always-on detections don't become a constant nuisance :
- false positivesThis is a classic problem. A poorly tuned rule can block legitimate traffic, break a purchase flow, or prevent an API from functioning as it should.
- Need for constant updatesIf firms and policies are not modernized, the WAF will remain blind to new attack techniques.
- Configuration complexityDefining good rules, understanding logs, and adjusting policies requires specialized knowledge.
- Impact on performanceEvery inspection adds a load. Poor design or a bad location can result in high latency.
- Evasion techniques by the attackers, who fragment packets, encode payloads in strange ways, or abuse protocol peculiarities to bypass controls.
Mitigating these challenges involves combining good initial design with continuous maintenance : establishing performance criteria, recording metrics (simultaneous users, requests per second, response times), defining clear roles (who manages rules, who reviews alerts, how often policies are reviewed), and integrating the WAF with the SOC, DevOps, and the organization's monitoring tools.
Best practices for getting the most out of always-on detection
To ensure your application firewall works in your favor and not against you, it's advisable to follow a series of practices that many manufacturers and security teams consider essential:
- Integrate the WAF with existing infrastructure (CDN, load balancers, proxies, SIEM, DDoS solutions, IPS) instead of viewing it as an “isolated cube”.
- Define performance and security KPIs from the outset (false positive rate, blocked attacks, added latency, etc.).
- Introduce specific WAF management roles, aligned with development, operations and SOC, so that the rules evolve along with the applications.
- Use preconfigured rule lists as a base, but adjust them to each application: define exceptions, specific whitelists and custom rules for critical flows.
- Integrate with event management platforms (SIEM) to correlate WAF logs with other sensors and get an overview.
- Review policies periodically, eliminating obsolete rules and adapting rate limiting thresholds, session control and protection against bots according to the actual behavior of users.
WAAP and WAAS: the evolution of WAF for modern applications and APIs
With the rise of cloud-native architectures, microservices, and APIs everywhere, the classic WAF has fallen short. Hence the emergence of Web Application and API Protection (WAAP) , often offered as Web Application & API Security (WAAS) as a service , which goes a step further:
- Automatic discovery of applications and API endpointspreventing services from being left exposed without protection.
- Importing API specifications (Swagger, OpenAPI, etc.) to validate that the requests comply with the defined contract.
- Specific protection for OWASP API Top 10 and for abuses of business logic in API calls.
- Integrated application-level bot and DDoS mitigationin addition to traditional WAF functions.
- Ability to apply different policies per endpointmaking those who manage sensitive data much tougher.
This approach reflects the current reality: many vulnerabilities no longer stem from the typical "classic" website, but rather from poorly documented APIs, neglected endpoints, and services exposed across multiple clouds . Automating their discovery and protecting them with the same always-on detection capabilities is crucial to preventing backdoors from being left open.
Overall, a good understanding of what a WAF does, how its continuous detection mechanisms operate, what deployment models exist, and how to integrate it with the rest of the security ecosystem allows you to build a much stronger defense around applications and APIs, reducing the risk of successful attacks without penalizing agility or user experience.
