Detection or Proof: Rethinking the Central Question Behind WAFs

A Web Application Firewall (WAF) is positioned in front of a web application, where incoming traffic is inspected against a set of policies. In effect, the WAF functions as a decision engine for Hypertext Transfer Protocol (HTTP) requests before they reach the application itself. While it may appear straightforward on the surface, it involves a greater degree of complexity than initially anticipated. After a sufficient number of security reviews, failed rule sets, and post-incident analyses, a recurring pattern is observed, where many teams continue to ask an outdated question about their WAF; namely whether the layer can detect attacks. While useful, this question is not considered sufficient. For modern applications, the more important question is what the layer is actually meant to determine. Traffic can be evaluated for whether it appears malicious, or whether it can be shown to be valid, expected, and safe. These two standards are not equivalent, and treating them as interchangeable is regarded as one of the most common design errors in web security.

The Limits of Detection

Attack detection continues to be considered valuable, as it is fast, scalable, and practical to deploy. Machine learning and deep learning models have repeatedly been shown to help WAF-like systems classify malicious web traffic, such as Cross-Site Scripting (XSS), Standard Query Language injection (SQLi), and Distributed Denial-of-Service (DDoS) attacks. Effective detection performance has been reported using deep learning and Convolutional Neural Network (CNN) methods ¹,². However, a built-in limitation is recognized in detection, where it generally asks whether something resembles a known bad pattern, or at least an anomalous one. As a result, detection is fundamentally about skepticism rather than a proof of legitimacy. A request can be crafted to evade a detector while still being harmful, and a request can appear suspicious while still being legitimate. For this reason, detection-only security is often found to create missed attacks and false positives simultaneously. This outcome is not attributed to a lack of effort, but to a limitation inherent to the method; it gets better at spotting malicious traffic, but not at proving safe behavior ³.

High-Risk Areas Need Proof

Consider a payment endpoint, a password-reset flow, a privileged administrative function, or a sensitive Representational State Transfer (REST) Application Programming Interface (API). In these areas, it is considered too weak to ask only whether a request “looks malicious.” What matters instead is whether the request is semantically valid (consistent with the intended business meaning and rules of the application), as well as structurally expected, authorized, and contextually acceptable. This is why some parts of a system are understood to require proof-oriented inspection; not merely confirmation that no attack is observed, but a demonstration that a request matches some allowed behavior. A 2025 paper examined Broken Object-Level Authorization (BOLA), a flaw through which a user can access or modify objects that should belong only to another user, and which is considered one of the most serious API security problems. In this study, REST APIs were modeled from Open API (a machine-readable description format for APIs) into Colored Petri Nets, a mathematical modeling method used to represent and analyze system behavior; these Colored Petri Nets were then used, together with execution logs, to detect authorization-related risks ⁴ An important implication drawn from this work is that some web risks are not merely payload-pattern problems, but logic and authorization problems, which are understood to require application-aware validation rather than generic attack spotting.

A Mixed Architecture, Not an Ideology

Many WAF strategies are considered to go wrong when the approach becomes ideological. One position holds that a WAF should detect attacks, and another holds that a WAF should allow only known-good traffic. Both positions are regarded as incomplete when treated as universal doctrine. Modern applications are understood as mixed environments. A public content page, a search box, and a product catalog endpoint may reasonably be protected through strong attack detection with tuned anomaly controls. A money-transfer endpoint, an identity workflow, a healthcare record update, or an administrative API, however, should typically be governed by stricter allow-list logic, schema validation, authorization checks, and business-rule enforcement. In other words, the inspection strategy is expected to match the business risk associated with each component. This conclusion is considered consistent with the literature, which demonstrates both the effectiveness of detection-oriented WAF models and the importance of dynamic, application-aware protection methods under changing threat conditions⁵. A useful WAF, therefore, is not expected to apply a single universal standard, rather, different standards are applied in different places. As illustrated in Figure 1, low-risk, high-volume surfaces are typically evaluated for resemblance to known attack patterns, while high-risk, high-consequence surfaces are typically evaluated for demonstrable acceptability against the only behavior that should be permitted. This is not regarded as inconsistency, but as mature design.

Conclusion

The most dangerous WAF failure is not considered to be the omission of one clever payload. Instead, the deeper failure is when an entire application is designed as though every endpoint deserves the same inspection logic. Modern web security is best treated not as a contest between detection and proof, but as a routing problem, in which each part of a system is assigned the level of assurance its risk actually warrants. Teams that make this assignment deliberately are found to build security controls that are cheaper where possible and stricter where necessary. Teams that do not typically end up with the worst of both outcomes; expensive controls applied where they are unnecessary, weak controls applied where they are unacceptable, and a false sense of consistency mistaken for genuine security. It is this failure to route, rather than any single missed attack, that constitutes the real WAF mistake.

References