# Cloudflare introduces stateful API vulnerability scanning in beta

> Cloudflare’s beta scanner begins with BOLA detection, deriving stateful tests from an OpenAPI call graph and separate owner and attacker contexts.

Canonical URL: https://www.devobs.io/news/news-cloudflare-api-vulnerability-scanner-beta/
By: Elias Brooks
Published: 2026-09-06T11:58:54.639Z
Updated: 2026-09-06T11:58:54.639Z
Event date: 2026-03-09
Section: Security

Cloudflare introduced a beta Web and API Vulnerability Scanner on March 9, beginning with tests for broken object-level authorization, or BOLA. The [launch post](https://blog.cloudflare.com/vulnerability-scanner/) says the open beta is available to API Shield customers. For the initial release, customers upload an OpenAPI document and provide credentials so the scanner can construct a stateful scan plan.

## Walk the API as a call graph

The scanner infers dependencies between endpoints in the OpenAPI document and builds a call graph. It then walks that graph using separate owner and attacker contexts. An owner creates a resource; an attacker, authenticated with a different set of valid credentials, tries to read, modify, or delete the resource it does not own. Successful access indicates an authorization vulnerability.

State matters because a later request may require data created by an earlier one. For example, an order-creation response can supply an identifier needed by a later update request. Cloudflare says Workers AI and structured outputs map response fields to later request parameters and generate test data where necessary.

## Treat findings as investigation leads

Teams evaluating the beta should prepare representative owner and attacker accounts and non-production data that can be used for active tests. They should review the uploaded OpenAPI document, the resources a scan may create, and the endpoints included in the resulting plan before running it against an environment.

A finding should lead to an application-level authorization review: confirm which principal made each request, which resource owner was expected, and where the server enforced that relationship. The scanner can exercise those relationships, but it does not replace them. Security teams should monitor application logs during initial scans and verify both a known-vulnerable test route and a protected route before using results in a release decision.

## Source references

- <https://blog.cloudflare.com/vulnerability-scanner/>