What is WAAP? Web Application and API Protection explained

WAAP stands for Web Application and API Protection. It is an analyst category rather than a product name, and it describes one cloud service that bundles four things people used to buy separately.

Gartner calls its version Cloud WAAP, which is why the term shows up in procurement documents at all.

The four components

A web application firewall. It checks requests against rules to find malicious payloads — SQL injection, cross-site scripting, known exploit signatures, path traversal. This is the oldest part, and the most commoditised.

DDoS mitigation. It soaks up volumetric floods and protocol attacks before they reach your origin, and it comes down to how much network capacity the vendor has, which is why CDN companies dominate the category.

Bot management. This is traffic that is well-formed, passes every WAF rule and is still unwanted. A WAF asks if a request is malicious. Bot management asks if the client is a person. Those are different questions, and they need different machinery.

API protection. This covers endpoint discovery, schema validation, and abuse of business logic. That last one maps onto API4 and API6 of the OWASP API Security Top 10 — resource consumption and sensitive business flows. It is also the part that overlaps heavily with bot management.

The four parts deal with unrelated failure modes. A vendor can be excellent at DDoS because it runs a large network, and mediocre at bot detection because that needs a different kind of signal. A WAAP score is an average, and averages hide the component you care about.

Who sells it

The category is dominated by CDN and web-infrastructure companies — Cloudflare, Akamai, Imperva, F5, AWS, Fastly and Radware — because they already run the global networks your traffic passes through, so adding security products on top of that network costs them very little. These are the names in Gartner's Cloud WAAP quadrant.

The vendors missing from that list are the specialists. Forrester's Q2 2026 Wave for Bot and Agent Trust Management names DataDome, HUMAN Security and Kasada as Leaders, and Arkose Labs, CHEQ and Netacea as Strong Performers. Almost none of those appear in the WAAP quadrant, and almost none of the WAAP vendors appear in the Wave.

That is not a contradiction. The two lists answer different buying questions — one about consolidated platforms, one about detection depth. We have written up how to read the two analyst views together, including why there is no Gartner Magic Quadrant for bot management at all.

On pricing, the WAAP vendors all do the same thing: they do not sell the bot component on its own. Cloudflare Bot Management is quoted inside the Cloudflare Enterprise contract, Akamai Bot Manager inside a CDN and security contract, and Imperva Advanced Bot Protection is usually bundled with WAF and API security. We keep the published and quoted positions for every vendor in one place in our enterprise bot protection pricing comparison.

The case for consolidation

It is real, and worth saying plainly rather than arguing against.

One contract. One console. One integration. One vendor to call. Four separate products mean four sets of credentials, four dashboards nobody looks at, and arguments about which layer dropped a request. For a team with no dedicated security function, a competent WAAP beats four best-of-breed products run badly. If bot traffic is a line on a compliance checklist rather than a cost on your P&L, buy the bundle and move on.

Where the bundle is weakest

Three things make the bot component the hardest of the four to do well inside a bundle.

Commodity automation versus a motivated adversary. A bundled bot module reliably stops declared crawlers, naive scripts and obviously wrong user-agents. It is much weaker against someone using a real, instrumented Chrome, driven through a residential proxy pool, rotating fingerprints, at human-plausible rates. At the request layer, that traffic looks exactly like a customer. To separate it you need signals the bundle usually does not collect: TCP-layer interrogation, client-side timing anchored in physical hardware, and proxy-network intelligence maintained by buying the proxies.

Explainability. Forrester and Gartner both mark bot vendors down on this repeatedly. Ask your current platform why it blocked a specific request. If the answer is a risk score between 0 and 100, you cannot act on it, you cannot argue with it when a customer complains, and under GDPR Article 22 you may not be able to give a data subject the meaningful information about the logic involved that they are entitled to.

Where the decision happens. A bundled bot module makes its decision in whichever place its vendor's network was already processing traffic. Detection that runs only on the server cannot see what the browser was doing, and detection that runs only in the browser is bypassed by any client that never runs the script, so a platform needs to collect signals in both places — and a bundle tends to have only the one its network already supported.

How to evaluate one

Four questions, in order of how much they will tell you.

1. For a single blocked request, which signal fired? If the platform cannot name it, you do not have a control you can operate, only a number you have to trust.
2. Which of the four components is actually strong? Make the vendor separate them. Ask for bot detection results on your traffic, not on their benchmark.
3. Where is the traffic processed, and under whose jurisdiction? A WAAP terminates TLS, so it sees everything. For a European operator this is a data-protection question with a real answer, not a formality.
4. What happens when it is wrong? Every detection layer has false positives. What separates vendors is whether you can find out which rule caused one and change it yourself, or whether you file a support ticket.

If the bundled answer holds up on all four, keep it. If question one has no answer, that is usually the whole conversation.