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.
Websites exposed to the internet receive requests that may contain well-known attack patterns, such as SQL injection and cross-site scripting (XSS). A WAF examines characteristics of these requests and can detect or block those that match known attack patterns, reducing the likelihood that some attacks reach the web application. Depending on the product and service plan, a WAF may also provide rate limiting, bot controls, and traffic-log visibility. [1]
The main roles of a WAF, from an executive and management perspective, can be summarized as follows.
| WAF capability | Organizational benefit | Important consideration |
|---|---|---|
| Detecting and blocking known attack patterns | Stops suspicious web requests before they reach the application | Protection applies to traffic the rules can recognize; a WAF cannot identify every attack |
| Virtual patching for certain vulnerabilities | May temporarily block specific exploit requests while a permanent fix is being prepared | The vulnerable software itself remains unpatched; coverage and bypass possibilities must be checked |
| Rate limiting and bot controls | May reduce excessive traffic and automated requests | Legitimate automation must be distinguished from abuse, and business impact must be tested; capabilities vary by product |
| Traffic logging and visibility | Provides clues about attack trends and blocking activity | Logs cannot be fully utilized without analysis and an operational response |
In short, a WAF is a measure for inspecting traffic at the entry point to a website and reducing known attacks and suspicious access. It is useful for protecting websites, but it is not a comprehensive mechanism for protecting servers, middleware, applications, or data.
Traffic destined for a website
|
v
+--------------------------+
| CDN / DDoS protection |
| (if deployed) |
+--------------------------+
|
v
+--------------------------+
| WAF |
| Inspects HTTP/HTTPS |
| Allows, logs, or blocks |
| traffic based on rules |
+--------------------------+
|
v
+--------------------------+
| Website / Web API |
+--------------------------+
|
v
+--------------------------+
| Authentication, |
| authorization, and |
| business rules |
+--------------------------+
|
v
+--------------------------+
| Databases / internal |
| services |
+--------------------------+
Note: If a route allows direct access to a public-facing server
without passing through the WAF, that traffic may not be
inspected by the WAF.
A WAF can protect only traffic that passes through it and that the product is capable of inspecting. Among other things, a WAF alone cannot resolve:
- Unauthorized operations carried out through a legitimate authenticated session
- Authorization flaws inside an application
- Weaknesses in unpatched middleware
- Activity inside a server after it has been compromised
A WAF is not an impenetrable suit of armor; it is one control within a defense-in-depth strategy. Organizations should not assume they are secure simply because a product has been deployed. They need to understand their own threats and business risks, and continuously maintain appropriate controls across infrastructure, applications, and operations.
4. Lessons from Incidents: Problems That Occurred at Different Layers from the WAF
When considering the limits of a WAF, it is useful to examine not only incidents involving the WAF itself or its configuration, but also incidents caused by weaknesses at other layers. This section looks at two distinct cases: a WAF/cloud configuration problem and an application API authorization problem.
Case 1: Capital One — A WAF Configuration Error Became a Path to Data (2019)
In 2019, unauthorized access to information concerning credit card applicants and customers occurred at Capital One, a U.S. financial institution. According to the U.S. Department of Justice's case summary, the intrusion took place through a misconfigured Web Application Firewall (WAF) that enabled access to the data.
This case shows that the presence of a WAF does not guarantee security: if the WAF or its surrounding configuration is incorrect, it can become part of an unintended access path. Inspecting traffic at the perimeter is not enough. Cloud credentials and permissions, as well as access controls for data storage, must be independently and properly designed and verified.
The lesson is not merely to check whether a WAF has been deployed. Organizations must manage the traffic paths to protected assets, WAF configuration, cloud permissions, and data-access controls as a connected whole. They must consider what operations become possible beyond the point where the WAF allows traffic—or beyond a path created by a WAF configuration error. [4]
Case 2: T-Mobile — Improper API Access-Control Configuration (2023)
In January 2023, T-Mobile, a U.S. telecommunications provider, disclosed that customer information had been improperly obtained through a single API. According to an investigation document issued by the U.S. Federal Communications Commission (FCC), a human configuration error resulted in improper API access controls, allowing an attacker to send queries to the API and obtain customer account information. Approximately 37 million current postpaid and prepaid customer accounts were affected. The specific information obtained varied by account.
The central issue in this case was not a conventional attack string or a server vulnerability. It was the management of which information an API should allow a user to access. Even when a request is correctly formatted and the API itself is a legitimate function, inadequate server-side authorization checks can allow access to information that should not be available to the requester.
The public materials do not establish whether a WAF was deployed in front of this API or whether a WAF was bypassed. It would therefore be inappropriate to describe this incident as a case in which “a WAF was bypassed.” The lesson here is that even when a WAF inspects traffic, the application itself must verify whether the user is authorized to obtain the requested data. [5]
What the Two Cases Tell Us
| Incident | Layer where the problem occurred | Management lesson |
|---|---|---|
| Capital One (2019) | WAF configuration and cloud access paths and permissions | Verify not only WAF configuration, but also permissions for cloud assets and data beyond it |
| T-Mobile (2023) | API access controls and application authorization | Verify authorization on the server for each user and each data object, even when the API request is legitimate |
These two incidents show that weaknesses in settings and controls at different layers can lead to data exposure. A WAF is an important defense point for inspecting incoming traffic, but it does not replace cloud permission management or application authorization. Organizations need accountable owners and verification procedures for each layer, and must confirm that each control is actually working.
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 |
I will delve into these in the next article.
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/
- U.S. Department of Justice, “United States v. Paige Thompson” — Case summary stating that the intrusion into Capital One's data occurred through a misconfigured Web Application Firewall that enabled access to the data. See also Capital One's announcement dated 29 July 2019, which describes unauthorized access involving the exploitation of a configuration vulnerability. DOJ case summary · Capital One incident announcement
- Federal Communications Commission (FCC), “In the Matter of T-Mobile US, Inc.”, DA 24-860 (2024) — Investigation and consent order documenting the API data-access incident identified in January 2023, including improperly configured access controls resulting from human error and the impact on approximately 37 million customer accounts. See also T-Mobile's announcement dated 19 January 2023. FCC document · T-Mobile announcement
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.
Top comments (0)