Introduction: What Is a WAF ? A Checkpoint for Incoming Web Traffic
A WAF (Web Application Firewall) is a security function that inspects HTTP/HTTPS traffic reaching websites and Web APIs. It applies predefined rules to decide whether to allow, log, or block that traffic. A useful way to understand it is as a checkpoint placed in front of a website.
Key Takeaways: What to Understand First
| Key point | Management implication |
|---|---|
| A WAF is useful, but it does not provide complete protection | Its protection is limited to the traffic it inspects and the attacks its configured rules can recognize |
| A WAF does not fix vulnerabilities themselves | It may temporarily suppress an exploit through virtual patching, but permanent remediation requires software updates or design changes |
| Attacks can abuse legitimate authenticated sessions | API operations and business-logic abuse that resemble normal traffic may be difficult for a conventional WAF to identify |
| Operations are required after deployment | Rule updates, false-positive tuning, log monitoring, coverage checks, and bypass-path testing are essential |
| Security is an ongoing management responsibility | Budgets, owners, and deadlines are needed for asset inventory, patch management, application authorization design, monitoring, and recovery |
1. There Are Boundaries to What a WAF Can Protect
Because a WAF operates at the entry point for web traffic, it can be effective against attacks that can be identified from the contents of that traffic. However, determining whether an application’s internal processing is correct, whether a logged-in user is entitled to access particular data, or whether a server or middleware component has an underlying weakness is not the WAF’s role.
| Weakness or risk | Why a WAF alone cannot resolve it | Fundamental response |
|---|---|---|
| Vulnerabilities in middleware or libraries | A WAF may temporarily block exploit traffic, but the software itself remains vulnerable | Apply security patches, upgrade to supported versions, and disable unnecessary features |
| Application authorization flaws | Even when a request is correctly formed, business logic must determine whether the user has permission to access the information or perform the action | Validate authorization on the server for each user, data object, and operation |
| Abuse of business logic | Repeatedly performing legitimate actions such as purchases, reservations, or applications may not look like a conventional attack pattern | Design business-specific limits, rate controls, abuse detection, and additional verification |
| Configuration and exposure errors | Administrative interfaces or direct routes to origin servers that bypass the WAF may remain outside its inspection scope | Inventory public exposure, enforce access controls, disable unnecessary services, and restrict network paths |
| Internal activity after compromise | A WAF is not designed to comprehensively control processes inside a server or lateral movement after a compromise | Apply least privilege, network segmentation, endpoint monitoring such as EDR, log analysis, and incident response |
Virtual Patching Is Not a Substitute for a Permanent Fix
This does not mean that a WAF can never address vulnerabilities specific to middleware. When a WAF can identify characteristics of HTTP requests that exploit a particular vulnerability, a rule may block those requests and buy time until the underlying software can be fixed. This approach is known as virtual patching.
However, virtual patching does not fix vulnerable code. It is effective only against attack patterns that the WAF can recognize in traffic it inspects. If an attacker changes the attack method or input format, or uses a route that bypasses the WAF, the protection may no longer apply. OWASP also explains that virtual patching should be used alongside permanent code remediation, and that the possibility of bypass must be evaluated. [2]
A WAF is therefore not a mechanism that makes vulnerability remediation unnecessary. It can serve as a temporary risk-reduction measure when an update or code change takes time, but the organization must still establish a deadline and assign an owner for the permanent fix.
2. Attacks That Look Like Legitimate Traffic Are Difficult for a WAF to Recognize
Attacks targeting websites and APIs do not always involve malicious strings or obviously abnormal requests. An attacker may register and log in just like an ordinary user, obtain a legitimate session, and then call APIs directly—without going through the normal website interface—to retrieve information or perform actions they are not authorized to carry out.
The term “site-based attack” does not identify a single, clearly defined attack method. In this article, we use the more concrete term “legitimate-looking API abuse” to describe this class of threats. It is not one specific technique; it can include authorization flaws in authenticated APIs, automation of business workflows, misuse of sessions, and related issues.
What Might This Look Like ?
- An attacker registers an account and logs in just like an ordinary user.
- Using the legitimate logged-in session, the attacker examines API requests that a browser sends during normal use.
- The attacker changes values in the requests—such as order numbers, customer IDs, or reservation numbers—or directly calls APIs that are not exposed through the normal user interface.
- If the server does not adequately verify authorization, the attacker may retrieve another user’s information or perform an action that should not be permitted.
- The attacker automates or repeats the same operations at scale, potentially harvesting information, occupying reservation slots, buying up inventory, or abusing points and coupons.
In this situation, the HTTP requests may be correctly formatted and accompanied by a valid logged-in session. They may contain none of the typical attack strings associated with SQL injection. From the WAF’s perspective, the traffic may look like an ordinary user calling a legitimate API.
OWASP’s API Security risks explicitly address this type of problem. For example, Broken Object Level Authorization (BOLA) describes cases in which changing an ID supplied to an API allows access to another user’s data. Unrestricted Access to Sensitive Business Flows addresses the risk that functions such as purchasing products or making reservations can be automated and abused. [3]
As one indication of the growth of automation, Thales’s 2026 Bad Bot Report states that, in data observed by the company during 2025, AI-powered bot attacks increased 12.5-fold year over year, and 21% of bot attacks targeted business logic. These figures are based on Thales’s own observation scope and should not be interpreted as statistics for the entire internet. Nevertheless, they illustrate why organizations need to consider not only the blocking of obviously malicious requests, but also how legitimate functions may be automated and abused. [6]
A key distinction here is the difference between authentication and authorization:
- Authentication: Verifying who is accessing the system.
- Authorization: Determining which information that user may view and which actions they may perform.
Successful login does not mean that access to all data and functions is permitted. Can a user view only their own order information ? Can they call administrative functions ? Under what frequency and conditions may they make reservations or payments ? These decisions must be enforced by the application according to its business rules.
Session IDs or authentication tokens may also be stolen and abused. Even when a WAF can inspect traffic, it cannot always determine from an HTTP request alone whether the person sending it is the legitimate user or a third party using a hijacked session. Session management, reauthentication for sensitive operations, and detection of abnormal usage patterns must be combined.
The Impact May Extend Beyond the Server Itself
If an application or middleware vulnerability is exploited and an attacker gains the ability to execute code on a server—a condition known as remote code execution (RCE)—the impact may extend beyond that individual server.
- Website content or files delivered to visitors may be altered.
- Visitors may be redirected to fraudulent websites or served malicious scripts.
- Credentials and database information stored on the server may be stolen.
- The server may become a foothold for attacks against internal networks or related services.
- The server may be used to send malicious traffic or distribute malicious content, damaging the reputation of the domain or service.
These outcomes are not inevitable in every incident. However, organizations that operate websites need to consider not only how to protect their servers, but also how an incident could affect customers, visitors, and connected partners.
3. Operational Burdens and Blind Spots Remain After WAF Deployment
A WAF does not automatically remain in an optimal state after installation. Rule sets must be updated, detection logs reviewed, false positives tuned, and policies reconsidered as services change.
| Operational issue | What may happen if it is neglected | Required management |
|---|---|---|
| False positives | Legitimate user access and business operations may be blocked | Assess the impact and manage exception rules with documented reasons and expiration dates |
| Detection-only configuration | An attack may be detected but not actually blocked | Check rule modes and how policies are applied in production |
| Outdated rules | New attack patterns or application changes may not be covered | Update rules and reassess them regularly |
| Gaps in coverage | Some domains, APIs, subdomains, or network paths may not pass through the WAF | Maintain an inventory of protected assets and traffic routes |
| Performance impact | Latency may increase and user experience may deteriorate | Monitor latency and error rates, and conduct load testing |
| Unused logs | Attack trends, false positives, or missed activity may go unnoticed | Correlate WAF logs with application, authentication, and server logs |
Particular attention should be paid to the traffic paths that the WAF actually protects. If a route remains that allows direct access to the origin server without passing through the WAF, traffic using that route will not be inspected by the WAF. Organizations should also verify where HTTPS traffic is decrypted and inspected, and whether communication types such as APIs and WebSockets are within the product’s protection scope.
In addition, continually adding exception rules to avoid false positives may eventually allow traffic that should have been blocked. Organizations must understand not merely whether they have purchased or deployed a WAF, but what traffic it inspects, what it blocks, and what it may fail to detect.
4. How to Build Defense in Depth with a WAF as One Component
To use a WAF effectively, protection must be designed to include the systems and controls both before and behind it. The objective is not to deploy many expensive products all at once. It is to understand the organization’s assets, threats, and business impact, set priorities, and improve continuously.
| Defense and management layer | Main activities | Relationship to the WAF |
|---|---|---|
| Asset and vulnerability management | Identify websites, APIs, servers, middleware, and libraries; manage support status and update deadlines | Identifies what the WAF should protect and addresses underlying vulnerabilities |
| Infrastructure and platform protection | Update operating systems, web servers, and middleware; stop unnecessary services; harden configurations; manage secrets | Reduces weaknesses that remain outside or behind the WAF |
| Application security | Secure implementation, code review, vulnerability assessment, authentication and authorization, and business-flow testing | Fixes application-specific flaws that a WAF cannot judge or correct |
| WAF and perimeter protection | Apply rules, rate limits, and bot controls; consolidate traffic paths; review logs | Detects and blocks attacks at the HTTP layer and reduces risk |
| Internal defense and data protection | Network segmentation, least privilege, database access controls, encryption, and backups | Limits the impact if an attacker gets past the WAF |
| Monitoring, response, and recovery | Log correlation, anomaly detection, incident procedures, recovery exercises, and customer communications | Helps identify signs of compromise and assess damage without relying only on WAF detection |
The WAF is one defense point in this structure, responsible for the HTTP layer. Depending on the assets and functions being protected, it may be useful to combine it with a CDN, DDoS protection, an API gateway, or bot management. However, it is important not to confuse the roles and responsibilities of these different components.
5. What Executives and Managers Should Verify
Executives and managers should not leave WAF performance and rule configuration entirely to the engineering team. Management should verify the following areas.
| Area to verify | Questions for executives and managers | Expected state or evidence |
|---|---|---|
| Identification of protected assets | Which websites, APIs, subdomains, and vendor-managed systems are publicly accessible ? | An up-to-date asset inventory with accountable owners |
| WAF coverage | Does all external-facing traffic pass through the WAF ? Are there routes that allow direct access ? | Traffic-flow diagrams, a list of protected assets, and periodic verification results |
| Rules and operations | Which rules are enabled, and why are exceptions allowed ? Are rules only detecting rather than blocking ? | Rule-update history, reasons and expiration dates for exceptions, and false-positive reviews |
| Vulnerability remediation | If the WAF temporarily blocks an exploit, when will the underlying vulnerability be permanently fixed ? | Remediation plans, owners, deadlines, and records of accepted unresolved risks |
| APIs and business logic | Can a logged-in user access another person’s information or functions outside their permissions ? | Object-level and function-level authorization tests, and tests for abuse of business workflows |
| Monitoring and incident response | Who makes decisions and who is notified when an attack or unauthorized operation is detected ? | Log monitoring, response procedures, contact lists, and exercise records |
| Budget and responsibilities | Are responsibilities for the WAF, application, infrastructure, and service providers clear ? | Contracts and responsibility boundaries, operating budgets, and improvement plans |
In particular, three matters should be made explicit as management decisions.
First, prioritize security measures. Do not make the same level of investment in every system by default. Assess the information handled, number of users, exposure, business impact of downtime, and potential damage from compromise. Systems handling customer or payment information, and systems essential to business continuity, may require a higher level of protection.
Second, do not treat WAF deployment as the completion of security work. Even after a WAF has been contracted and installed, protection cannot be considered sufficient unless rules are properly applied, logs are reviewed, exceptions are managed, and vulnerabilities in the protected systems are remediated. Assign an owner for ongoing operations and define performance and effectiveness measures.
Third, budget for long-term improvement. Updating operating systems, web servers, middleware, CMS platforms, plugins, and applications requires continuing investment in people and time. Even when replacing the underlying platform is not immediately possible, set separate plans and deadlines for interim controls, permanent remediation, and migration or retirement.
Conclusion: What Matters Is Not Having Deployed a WAF, but Being Able to Maintain Protection
A WAF is not an unnecessary product. When properly deployed, configured, and operated, it can detect and block many attacks against web applications and buy time for vulnerability remediation.
However, a WAF does not turn a vulnerable platform into a secure one. It cannot, by itself, completely prevent API abuse through legitimate sessions, application authorization flaws, intrusion into internal networks, or malicious activity after a compromise. Treating WAF deployment as a reason to say “we are secure” risks overlooking fundamental weaknesses and postponing necessary work.
The responsibility of executives and managers is not simply to increase the number of security products deployed. They must understand their organization’s systems and data, analyze which threats create which business risks, and put controls in place across infrastructure, applications, users, and operations. They must then review those controls regularly and continue vulnerability remediation, monitoring, exercises, and recovery preparation.
A WAF is not an impenetrable suit of armor. Use it properly as one part of defense in depth, understand the weaknesses that remain, and keep addressing them. That is what security management requires to protect customers and the business.
References
- AWS, “AWS WAF Documentation” — Describes how WAF inspects web requests forwarded to protected resources and can count, block, allow, or challenge requests according to configured conditions. Features and coverage vary by product. https://docs.aws.amazon.com/waf/
- OWASP, “Virtual Patching Cheat Sheet” — Explains virtual patching, its value in temporarily blocking known exploit paths, the fact that the underlying vulnerability remains, and the need to test for bypasses and implement permanent fixes. https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
- OWASP API Security Top 10 – 2023 — Covers API1, “Broken Object Level Authorization”; API5, “Broken Function Level Authorization”; and API6, “Unrestricted Access to Sensitive Business Flows,” among other risks involving API authorization flaws and abuse of business workflows. https://api-security.owasp.org/editions/2023/en/0x11-t10/ 4-5. See previous article.
- Thales, “2026 Bad Bot Report” — Industry report analyzing bot activity based on data observed by Thales during 2025, including AI-powered bot activity and attacks targeting business logic. The figures represent Thales’s observation scope and are not statistics for the entire internet. https://cpl.thalesgroup.com/resources/application-security/2026-bad-bot-report
- OWASP API Security Project, “API6:2023 Unrestricted Access to Sensitive Business Flows” — Explains the risks and mitigations associated with the automation and excessive use of sensitive business workflows such as purchases, posts, and reservations. https://api-security.owasp.org/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/
This article does not reject WAFs. It recognizes their value while clarifying the limits of their protection and the need to combine them with other controls. Always verify the specific features, supported protocols, and inspection coverage against the specifications and configuration of the WAF product in use.