API attacks are logic failures, not signature matches
Web application vulnerabilities such as SQL injection and cross-site scripting (XSS) tend to be detectable by pattern: they look like code where data should be, or script tags in form fields. API vulnerabilities do not follow that rule. A Broken Object Level Authorization (BOLA) attack, the top entry on the OWASP API Top 10, uses fully valid HTTP requests that meet protocol and schema requirements but violate business logic.
Consider a food delivery app whose backend is an API. The endpoint /api/v1/orders accepts a PATCH request from an authenticated user. If an attacker, User A, submits a request to change the delivery address on an order belonging to User B, that request carries a valid token and a correct schema. The only defect is that the endpoint fails to confirm User B owns the resource identified by the {order_id}. A standard WAF or bot management system will let this traffic through because nothing about it is malformed.
The fix is a simple authorization check, e.g. if (order.userID != user.ID) throw Unauthorized;, but finding the absence of such a check requires active testing. This is why Cloudflare is now announcing the beta of its Web and API Vulnerability Scanner, available first to API Shield customers. It is a stateful Dynamic Application Security Testing (DAST) tool designed to hunt for logic flaws rather than signatures. The initial release focuses on BOLA, with additional API and web application vulnerability types to follow.
Why passive detection has limits
Passive scanning for API vulnerabilities requires context. Cloudflare launched BOLA vulnerability detection in November 2025 for API Shield, using traffic analysis to find anomalies in how API parameters are used. To succeed, the scanner must understand what a valid API call looks like, which parameters are variable, how typical users behave, and how the API responds to manipulated inputs.
Not every environment provides that context. Development environments often lack real user traffic. Production environments may not be receiving enough attack traffic for analysis. Teams can fall back on DAST, which generates net-new traffic profiles expressly for security testing. But legacy DAST tools have a high barrier to entry: they require manual Swagger/OpenAPI file uploads, struggle with modern login flows, and often ship with few or no API-specific tests such as BOLA.
Stateful scanning at the edge
Traditional DAST tools treat each request in isolation, but finding broken authorization requires chaining requests together in the same logical order an attacker would use. In a live security test, you must create your own objects before testing whether the API lets one user act on another's. A stateful scanner can maintain that sequence; a request-by-request scanner cannot.
Cloudflare's approach differs from legacy DAST in several specific ways:
- Scan results appear in Security Insights alongside other Cloudflare security findings, so posture data is not siloed.
- Cloudflare's API Discovery and Schema Learning already catalog customer endpoints and traffic patterns. For the initial release, customers manually upload an OpenAPI spec; a future release will remove that step.
- Because Cloudflare sits at the edge, it can convert passive traffic observations into active probes, making it straightforward to verify BOLA risks found through traffic inspection by sending new HTTP requests.
- The DAST platform is built from the ground up as stateful. Customers provide API credentials, and Cloudflare constructs a scan plan from the uploaded API schemas, skipping the hours of manual setup legacy tools require.
With the scanner, security teams can actively test APIs in development or production at any time, without waiting for attack traffic or needing to pre-define normal behavior. The stateful design is what makes it feasible to test authorization controls: the scanner can create an object with one identity and then use another identity to attempt access, reproducing the exact request pattern that exposes BOLA vulnerabilities.
From OpenAPI specs to attack plans
Building an automatic scan plan starts with parsing the API's OpenAPI schema, which defines endpoints (host, method, path), expected request parameters, and response structures. The scanner constructs an API call graph from this document and walks it from two perspectives: owners who create resources and attackers who attempt to access them. Attackers authenticate with their own valid credentials. If an attacker can read, modify, or delete a resource they don't own, the scanner flags an authorization vulnerability.
This model requires understanding data dependencies between endpoints. For a delivery order with ID 8821, a server-side resource only exists after an owner creates it via a "genesis" POST request with minimal dependencies. Subsequent requests, such as an attacker's PATCH, carry a data dependency on that genesis request — the order_id value must come from the earlier response before the PATCH can proceed.
The purple arrows in the diagram above show the nodes required to reach the POST /api/v1/orders/{order_id}/note/{note_id} endpoint. None of this inferred dependency logic appears explicitly in the OpenAPI specification — the scanner must derive it automatically.
Two challenges make this inference difficult. First, OpenAPI documents vary in data quality. Second, even complete schemas use inconsistent naming. In a typical specification, a POST response might contain an id field that a human immediately recognizes as the value for order_id in a later PATCH request. But that property could equally be named orderId, value, or something else entirely, nested at arbitrary depths. These inconsistencies defeat heuristics.
openapi: 3.0.0
info:
title: Order API
version: 1.0.0
paths:
/api/v1/orders:
post:
summary: Create an order
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
product:
type: string
count:
type: integer
required:
- product
- count
responses:
'201':
description: Item created successfully
content:
application/json:
schema:
type: object
properties:
result:
type: object
properties:
id:
type: integer
created_at:
type: integer
errors:
type: array
items:
type: string
/api/v1/orders/{order_id}:
patch:
summary: Modify an order by ID
parameters:
- name: order_id
in: path
The scanner addresses this with Cloudflare's Workers AI platform. An open-weight model such as gpt-oss-120b is capable of matching data dependencies and generating realistic fake data, filling gaps in OpenAPI schemas. Using structured outputs, the model produces a machine-readable representation of the API call graph, which the scanner then walks while injecting attacker and owner credentials appropriately.
This replaces human inference of authorization and data relationships with AI-driven inference, and structured outputs convert the model's natural-language reasoning back into executable instructions. Self-hosting on Workers AI also means the system inherits Cloudflare's globally distributed, highly available architecture.
Infrastructure and credential handling
Gaining customer trust requires proven infrastructure. For the scanner's control plane, Cloudflare integrated Temporal, a durable execution framework already used by internal services to manage the complexity of multiple test plans per scan. The backend is written in Rust, consistent with Cloudflare's broader infrastructure, enabling reuse of internal libraries and potential future integration with systems like FL2 or the Flamingo test framework.
Handling API credentials responsibly is central to the design. The scanner uses HashiCorp's Vault Transit Secret Engine (TSE) for encryption-as-a-service. On submission, credentials are immediately encrypted by TSE — which performs encryption but does not store ciphertext — and then saved on Cloudflare infrastructure. The public API layer has no decryption authorization.
Decryption happens only at the final stage, when a TestPlan issues a request to the customer's infrastructure. Only the executing Worker is authorized to request decryption, a restriction reinforced with strict typing in Rust to keep access to decryption methods minimal. Credentials are further protected through regular rotation and periodic rewraps via TSE, ensuring the system interacts only with new ciphertext and never exposes the original secret.
Launch and roadmap
BOLA vulnerability scanning enters Open Beta today for all API Shield customers. Scans, configuration changes, and results can be managed programmatically through the Cloudflare API for integration into CI/CD pipelines or security dashboards. Developer documentation for starting BOLA scans is available for API Shield customers.
BOLA was chosen as the starting point because it is both the hardest API vulnerability to solve and the highest risk for most customers. The scanning engine is built to be extensible, and near-term plans include covering popular OWASP Web Top 10 vulnerabilities, including SQL injection (SQLi) and cross-site scripting (XSS). A waitlist is available for notification when the engine expands beyond API-specific threats.
