Is the WAF Obsolete? Why Signatures Alone Are Not Enough
Why WAF inspection still matters as AI-assisted attacks increase the need for behavioural context, API protection and policy-driven enforcement.
A login request can be perfectly valid HTTP and still be part of a credential-stuffing campaign. A sequence of ordinary API calls can extract valuable data. Repeated requests to an expensive operation can exhaust application resources without containing a recognisable injection payload.
These examples expose a limitation in how application protection is sometimes understood: inspecting the contents of an individual request cannot explain everything about the activity it belongs to.
AI-assisted attack tools add urgency to that problem. They can help attackers work faster and automate more of their activity. The defensive response needs to account for request content, behaviour and the context in which an operation takes place.
WAF functionality remains valuable. What deserves reconsideration is the assumption that matching requests against known attack patterns provides sufficient application protection.
AI increases the pressure on existing weaknesses
The UK’s National Cyber Security Centre assesses that AI will make elements of cyber intrusion more effective and efficient. Its assessment of the cyber threat through 2027 anticipates greater attack volume and impact through improvements to existing techniques, including vulnerability research and exploitation of known flaws.
For application owners, this strengthens an existing operational problem: attackers can move faster than organisations can consistently identify, fix and verify every exposed weakness.
Some of that activity will still produce familiar attack payloads. Other activity may use valid credentials, legitimate application functions or automated interactions whose harmful purpose emerges over time. The OWASP Automated Threats project documents this broader class of application abuse.
That makes several defensive responsibilities more urgent: patching, secure application design, authentication, authorisation and the ability to recognise abuse across related requests. A protection gateway contributes to those defences, while the application remains responsible for enforcing its own access rules and business logic.
Where WAF fits within WAAP
A Web Application Firewall inspects application traffic and applies controls to requests and, where supported, responses. That remains an important enforcement point for detecting suspicious input, restricting unwanted traffic and applying temporary protection around a known vulnerability.
Web Application and API Protection, or WAAP, brings a broader set of responsibilities together. OWASP’s runtime protection guide describes this combination of WAF, API protection, bot management and application-layer DDoS controls.
| Protection area | The question it helps answer |
|---|---|
| WAF inspection | Does this request contain suspicious input or violate an application traffic rule? |
| API protection | Does the request conform to the endpoint’s permitted methods, structure and access requirements? |
| Bot management | Is this automated activity permitted, and is its behaviour acceptable? |
| Application-layer DDoS controls | Is traffic consuming application resources at an unacceptable rate? |
These are responsibilities to examine when evaluating a platform, rather than guarantees attached to a product name. A product marketed as a WAF may already provide several of them. API discovery and schema enforcement, for example, should be assessed as specific capabilities.
Application-layer availability controls also have a defined scope. Request and connection limits can help protect application capacity; protecting a saturated network connection requires suitable network capacity and upstream DDoS protection.
Signatures and rules still have a job to do
A well-chosen rule can provide a precise response to a known problem. An application owner may need to restrict a vulnerable parameter, reject an unexpected content type or block a request pattern associated with an active exploit.
Rule-based inspection can also do more than look for one exact string. The OWASP Core Rule Set uses anomaly scoring to combine rule matches when evaluating traffic. Rules and signatures are therefore not synonymous with simplistic matching.
Their coverage still depends on what is inspected and what the rules express. A request can satisfy structural checks and contain no recognisable exploit while contributing to an abusive sequence of otherwise permitted operations.
This is where additional context becomes useful.
Behaviour adds context to the request
Consider repeated login attempts. The content of an individual request may reveal little. The distribution of attempts, their frequency and their relationship to observed failures may provide a stronger indication of abuse.
Similar reasoning applies to repeated exports, costly searches or automated collection of application data. Understanding the activity may require observations across a route, account, session or other relevant scope. A per-address limit alone may miss distributed activity and can also affect unrelated users who share an address.
This is a general design requirement for application protection; the exact signals and scopes available depend on the deployment. Information from the application can add context that a gateway cannot reliably infer.
Behaviour also needs interpretation. A legitimate integration may generate sustained automated traffic. A customer behind a shared proxy may inherit an address’s poor reputation. A sudden increase in requests may reflect a successful campaign or an attack. The platform needs a policy for acting on those observations, with enough evidence to investigate the result.
Machine learning and behavioural analysis have different roles
Machine learning describes a method; behavioural analysis describes a source of evidence. They can overlap, but they are not interchangeable.
An ML inspection engine may assess the content of a request. A behavioural detector may examine patterns of activity. IP reputation adds information about an address’s observed history. Explicit rules can define how these inputs affect a protected operation.
Each contributes a different view. Combining them requires attention to the subject of the observation, its reliability and how long it remains relevant. A model score and a reputation entry should not acquire unlimited authority simply because they can be expressed as numbers.
Operational quality matters as much as detection. Legitimate traffic changes, models require evaluation and exceptions need a defined scope. Useful protection includes the ability to identify false positives and adjust policy without weakening unrelated controls.
Turn observations into proportionate action
A suspicious observation does not always justify the same response. A platform may allow traffic, apply a limit, require a challenge or block an operation, according to its configured capabilities and policy.
The choice should reflect what is being protected. A login endpoint, a public information page and a costly API operation have different abuse patterns and operational consequences. A challenge may be appropriate for an interactive browser operation; a machine-to-machine API needs controls suited to automated clients.
In our Sovereign Fortress High Assurance WAAP, application protection combines ML-based inspection, behavioural and automation signals, IP reputation and explicit risk policy. Our CAPTCHA provides a challenge mechanism for protected browser interactions. Request-path inspection and asynchronous risk processing have different responsibilities and timing; they do not have to form one universal pipeline.
The architectural detail is explored in Security Signals, Risk Decisions and Enforcement. The central requirement is that the relationship between an observation, a policy decision and the resulting gateway action remains understandable.
The protection platform needs protection too
A gateway processes input supplied by parties it does not control. Its parsers, inspection engines and supporting services therefore form part of the attack surface.
The wider Sovereign Fortress architecture addresses the authority of those components through SELinux Type Enforcement, Linux namespaces, restricted Linux capabilities and controlled communication. SELinux governs resource access, namespaces separate selected resource views, and capability restrictions limit privileged operations. Together, these controls help limit what a compromised component can access or change.
That responsibility complements traffic inspection. One evaluates requests passing through the platform; the other constrains the platform’s own processes. Protecting the WAF Itself examines that part of the design.
A broader standard for application protection
WAF inspection continues to provide a useful part of application defence. AI-assisted attacks increase the importance of combining that inspection with API controls, behavioural evidence, automation management and proportionate enforcement.
When evaluating an application protection platform, ask how it recognises abuse that spans multiple requests, how it handles legitimate automation, how its decisions can be investigated and how its own components are confined.
Those questions provide a more useful basis for assessing protection than the product label alone.