WAAP, web application and API protection, is the name for a set of controls placed in front of web applications and APIs: a web application firewall plus API aware inspection, rate and abuse limits, and bot handling. It reduces exposure to known attack patterns. It cannot fix broken authorization inside your application.
How is WAAP different from a WAF?
NIST SP 800-41 Rev. 1 describes the web application firewall as a specialized application firewall that sits in front of a web server and detects many of the ways attackers exploit HTTP. It also remarks that the technology is relatively new and the threats it addresses change frequently, so rules need ongoing tuning.
WAAP is a product category name, not a standard, so the exact feature list varies by supplier. The shared idea is that traffic in front of an application is now more than browser pages. Mobile apps, partner integrations and single page front ends talk to APIs, with JSON bodies, tokens and many endpoints. Inspecting those well needs knowledge of the API's shape, not only generic signatures.
What does the rule engine actually look for?
The OWASP Core Rule Set is the best documented open example. It is a set of generic attack detection rules for ModSecurity or compatible firewalls, aiming to protect against a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. It covers categories such as SQL injection, cross site scripting and local file inclusion.
Generic rules work on patterns in requests. That is useful against commodity scanning and known injection strings. It is weak against anything that looks like a perfectly valid request.
Which API risks can a WAAP not fix?
Read the OWASP API Security Top 10 for 2023 with this question in mind. The list includes broken object level authorization (API1), broken authentication (API2), broken object property level authorization (API3), unrestricted resource consumption (API4), broken function level authorization (API5), unrestricted access to sensitive business flows (API6), server side request forgery (API7), security misconfiguration (API8), improper inventory management (API9) and unsafe consumption of APIs (API10).
A request that fetches another customer's order by changing an ID is syntactically normal and carries a valid token. The gateway cannot know that this user should not see that order. Only the application knows. Resource limits and business flow limits, such as rate caps per account, are areas where WAAP style controls do help. Inventory is another: OWASP notes APIs expose more endpoints than traditional web apps, so a current list of hosts and versions is needed to avoid deprecated versions and exposed debug endpoints.
A constructed example
A retailer puts an inspection layer in front of its mobile API. In the first week it blocks a wave of scripted login attempts and a handful of injection probes. Good. A month later a researcher reports that changing the order number in a request returns another user's receipt. The inspection layer passed it, because nothing about it looks malicious. The fix is an ownership check in the order service. The retailer then adds a test that fails if any order endpoint omits that check.
How to check or apply this
- List your public applications and APIs, including mobile and partner endpoints. Keep the list current, since OWASP flags inventory as its own risk.
- Start the protection layer in detect only mode and read the logs for a few weeks before blocking. Generic rules can produce false positives on legitimate traffic.
- Load API definitions where your tool supports it, so requests can be checked against the expected paths, methods and fields.
- Set rate and size limits per client and per endpoint to address unrestricted resource consumption.
- Separately, test authorization in code: object level and function level checks on every endpoint, with automated tests.
- Treat the protection layer as a second line. Fix the underlying flaw and keep dependency updates flowing.
- Review rule changes and exceptions on a schedule, and measure blocked, allowed and overridden requests.
Where does Safeguard fit?
Safeguard works on the application side of this split: SAST and dependency scanning find code and library flaws, and reachability analysis shows which are exercised. Those findings tell you what to fix in the service itself, which an inspection layer in front of it cannot do.
Quick check
Will a WAAP stop broken object level authorization?
Not reliably. The request looks valid, so the control point is authorization logic in the application, backed by tests.
Is the OWASP Core Rule Set a WAAP?
No. It is a free rule set for compatible web application firewalls. A WAAP offering usually adds API awareness, rate limits and bot controls around that kind of engine.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- OWASP API Security Top 10 2023
- OWASP Core Rule Set
Last reviewed: 18 October 2026.
