Safety is historically a recreation of protection. You construct partitions, arrange gates, and write guidelines to dam visitors that appears suspicious. For years, Cloudflare has been a frontrunner on this house: our Software Safety platform is designed to catch assaults in flight, dropping malicious requests on the edge earlier than they ever attain your origin. However for API safety, defensive posturing isn’t sufficient.
That’s why right now, we’re launching the beta of Cloudflare’s Net and API Vulnerability Scanner.
We’re beginning with essentially the most pervasive and difficult-to-catch menace on the OWASP API Prime 10: Damaged Object Degree Authorization, or BOLA. We are going to add extra vulnerability scan varieties over time, together with each API and net software threats.
Probably the most harmful API vulnerabilities right now aren’t generic injection assaults or malformed requests {that a} WAF can simply spot. They’re logic flaws—completely legitimate HTTP requests that meet the protocol and software spec however defy the enterprise logic.
To search out these, you may’t simply look ahead to an assault. You need to actively hunt for them.
The Net and API Vulnerability Scanner can be obtainable first for API Defend clients. Learn on to be taught why we’re centered on API safety scans for this primary launch.
Why purely defensive safety misses the mark
Within the net software world, vulnerabilities typically appear to be syntax errors. A SQL injection try appears to be like like code the place knowledge needs to be. A cross-site scripting (XSS) assault appears to be like like a script tag in a type subject. These have signatures.
API vulnerabilities are totally different. As an instance, let’s think about a meals supply cellular app that communicates solely with an API on the backend. Let’s take the orders endpoint:
Endpoint Definition: /api/v1/orders
Methodology | Useful resource Path | Description |
GET | /api/v1/orders/{order_id} | Test Standing. Returns the monitoring standing of a selected order (e.g., “Kitchen is preparing”). |
PATCH | /api/v1/orders/{order_id} | Replace Order. Permits the person to switch the drop-off location or add supply directions. |
In a damaged authorization assault like BOLA, Person A (the attacker) requests to replace the supply handle of a paid-for order belonging to Person B (the sufferer). The attacker merely inserts Person B’s {order_id} within the PATCH request.
Here’s what that request appears to be like like, with ‘8821’ as Person B’s order ID. Discover that Person A is absolutely authenticated with their very own legitimate token:
PATCH /api/v1/orders/8821 HTTP/1.1
Host: api.instance.com
Authorization: Bearer
Content material-Sort: software/json
{
"delivery_address": "123 Attacker Way, Apt 4",
"instructions": "Leave at front door, ring bell"
}
The request headers are legitimate. The authentication token is legitimate. The schema is appropriate. To a typical WAF, this request appears to be like excellent. A bot administration providing might even be fooled if a human is manually sending the assault requests.
Person A will now get B’s meals delivered to them! The vulnerability exists as a result of the API endpoint fails to validate if Person A truly has permission to view or replace person B’s knowledge. It is a failure of logic, not syntax. To repair this, the API developer may implement a easy test: if (order.userID != person.ID) throw Unauthorized;
You’ll be able to detect these kind of vulnerabilities by actively sending API take a look at visitors or passively listening to present API visitors. Discovering these vulnerabilities via passive scanning requires context. Final yr we launched BOLA vulnerability detection for API Defend. This detection robotically finds these vulnerabilities by passively scanning buyer visitors for utilization anomalies. To achieve success with such a scanning, it’s essential know what a “valid” API name appears to be like like, what the variable parameters are, how a typical person behaves, and the way the API behaves when these parameters are manipulated.
But there are causes safety groups might not have any of that context, even with entry to API Defend’s BOLA vulnerability detection. Growth environments might should be examined however lack person visitors. Manufacturing environments might (fortunately) have a scarcity of assault visitors but nonetheless want evaluation, and so forth. In these circumstances, and to be proactive normally, groups can flip to Dynamic Software Safety Testing (DAST). By creating net-new visitors profiles meant particularly for safety testing, DAST instruments can search for vulnerabilities in any setting at any time.
Sadly, conventional DAST instruments have a excessive barrier to entry. They’re typically tough to configure, require you to manually add and preserve Swagger/OpenAPI recordsdata, battle to authenticate appropriately towards trendy advanced login flows, and may merely lack any API-specific safety exams (e.g. BOLA).
Cloudflare’s API scanning benefit
Within the meals supply order instance above, we assumed the attacker may discover a legitimate order to switch. Whereas there are sometimes avenues for attackers to assemble such a intelligence in a reside manufacturing setting, in a safety testing train you could create your individual objects earlier than testing the API’s authorization controls. For typical DAST scans, this could be a downside, as a result of many scanners deal with every particular person request by itself. This methodology fails to chain requests collectively within the logical sample crucial to search out damaged authorization vulnerabilities. Legacy DAST scanners may also exist as an island inside your safety tooling and orchestration setting, stopping their findings from being shared or considered in context.
Vulnerability scanning from Cloudflare is totally different for just a few key causes.
First, Safety Insights will listing outcomes from our new scans alongside any present Cloudflare safety findings for added context. You’ll see all of your posture administration data in a single place.
Second, we already know your API’s inputs and outputs. In case you are an API Defend buyer, Cloudflare already understands your API. Our API Discovery and Schema Studying options passively catalog your endpoints and be taught your visitors patterns. When you’ll have to manually add an OpenAPI spec to get began for our preliminary launch, it is possible for you to to get began shortly with out one in a future launch.
Third, as a result of we sit on the edge, we are able to flip passive visitors inspection data into lively intelligence. It is going to be straightforward to confirm BOLA vulnerability detection dangers (discovered by way of visitors inspection) by sending net-new HTTP requests with the vulnerability scanner.
And eventually, we have now constructed a brand new, stateful DAST platform, as we element beneath. Most scanners require hours of setup to “teach” the software how you can speak to your API. With Cloudflare, you may successfully skip that step and get began shortly. You present the API credentials, and we’ll use your API schemas to robotically assemble a scan plan.
Constructing automated scan plans
APIs are generally documented utilizing OpenAPI schemas. These schemas denote the host, methodology, and path (generally, an “endpoint”) together with the anticipated parameters of incoming requests and ensuing responses. In an effort to robotically construct a scan plan, we should first make sense of those API specs for any given API to be scanned.
Our scanner works by build up an API name graph from an OpenAPI doc and subsequently strolling it, utilizing attacker and proprietor contexts. Homeowners create assets, attackers subsequently attempt to entry them. Attackers are absolutely authenticated with their very own set of legitimate credentials. If an attacker efficiently reads, modifies or deletes an unowned useful resource, an authorization vulnerability is discovered.
Think about for instance the above supply order with ID 8821. For the server-side useful resource to exist, it wanted to be initially created by an proprietor, more than likely in a “genesis” POST request with no or minimal dependencies (earlier crucial calls and ensuing knowledge). Modelling the API as a name graph, such an endpoint constitutes a node with no or few incoming edges (dependencies). Any subsequent request, such because the attacker’s PATCH above, then has a knowledge dependency (the information is order_id) on the genesis request (the POST). With out all knowledge supplied, the PATCH can’t proceed.
Right here we see in purple arrows the nodes on this API graph which can be crucial to go to so as to add a be aware to an order by way of the POST /api/v1/orders/{order_id}/be aware/{note_id} endpoint. Importantly, not one of the steps or logic proven within the diagram is offered within the OpenAPI specification! It should be inferred logically via another means, and that’s precisely what our vulnerability scanner will do robotically.
In an effort to reliably and robotically plan scans throughout quite a lot of APIs, we should precisely mannequin these endpoint relationships from scratch. Nevertheless, two issues come up: knowledge high quality of API specs is just not assured, and even functionally full schemas can have ambiguous naming schemes. Think about a simplified OpenAPI specification for the above API, which could appear to be
openapi: 3.0.0
information:
title: Order API
model: 1.0.0
paths:
/api/v1/orders:
publish:
abstract: Create an order
requestBody:
required: true
content material:
software/json:
schema:
sort: object
properties:
product:
sort: string
depend:
sort: integer
required:
- product
- depend
responses:
'201':
description: Merchandise created efficiently
content material:
software/json:
schema:
sort: object
properties:
end result:
sort: object
properties:
id:
sort: integer
created_at:
sort: integer
errors:
sort: array
objects:
sort: string
/api/v1/orders/{order_id}:
patch:
abstract: Modify an order by ID
parameters:
- title: order_id
in: path
We will see that the POST endpoint returns responses reminiscent of
{
"result": {
"id": 8821,
"created_at": 1741476777
},
"errors": []
}
To a human observer, it’s shortly evident that $.end result.id is the worth to be injected in order_id for the PATCH endpoint. The id property may also be referred to as orderId, worth or one thing else, and be nested arbitrarily. These refined inconsistencies in OpenAPI paperwork of arbitrary form are intractable for heuristics-based approaches.
Our scanner makes use of Cloudflare’s personal Employees AI platform to deal with this fuzzy downside house. Fashions reminiscent of OpenAI’s open-weight gpt-oss-120b are highly effective sufficient to match knowledge dependencies reliably, and to generate sensible pretend knowledge the place crucial, basically filling within the blanks of OpenAPI specs. Leveraging structured outputs, the mannequin produces a illustration of the API name graph for our scanner to stroll, injecting attacker and proprietor credentials appropriately.
This strategy tackles the issue of needing human intelligence to deduce authorization and knowledge relationships in OpenAPI schemas with synthetic intelligence to do the identical. Structured outputs bridge the hole from the pure language world of gpt-oss again to machine-executable directions. Along with Employees AI fixing the planning downside, self-hosting on Employees AI means our system robotically advantages from Cloudflare’s extremely obtainable, globally distributed structure.
Constructed on confirmed foundations
Constructing a vulnerability scanner that clients will belief with their API credentials calls for confirmed infrastructure. We didn’t reinvent the wheel right here. As a substitute, we built-in providers which have been validated and deployed throughout Cloudflare for 2 essential elements of our scanner platform: the scanner’s management aircraft and the scanner’s secrets and techniques retailer.
The scanner’s management aircraft integrates with Temporal for Scan Orchestration, on which different inside providers at Cloudflare already rely. The complexity of the quite a few take a look at plans executed in every Scan is successfully managed by Temporal’s sturdy execution framework.
The whole backend is written in Rust, which is extensively adopted at Cloudflare for infrastructure providers. This lets us reuse inside libraries and share architectural patterns throughout groups. It additionally positions our scanner for potential future integration with different Cloudflare programs like FL2 or our take a look at framework Flamingo – enabling eventualities the place scanning may coordinate extra tightly with edge request dealing with or testing infrastructure.
Credential safety via HashiCorp’s Vault Transit Secret Engine
Scanning for damaged authentication and damaged authorization vulnerabilities requires dealing with API person credentials. Cloudflare takes this duty very significantly.
We be certain that our public API layer has minimal entry to unencrypted buyer credentials by utilizing HashiCorp’s Vault Transit Secret Engine (TSE) for encryption-as-a-service. Instantly upon submission, credentials are encrypted by TSE—which handles the encryption however doesn’t retailer the ciphertext—and are subsequently saved on Cloudflare infrastructure.
Our API is just not licensed to decrypt this knowledge. As a substitute, decryption happens solely on the final stage when a TestPlan makes a request to the shopper’s infrastructure. Solely the Employee executing the take a look at is allowed to request decryption, a restriction we strengthen utilizing strict typing with extra security rails inside Rust to implement minimal entry to decryption strategies.
We additional safe our clients’ credentials via common rotation and periodic rewraps utilizing TSE to mitigate danger. This course of means we solely work together with the brand new ciphertext, and the unique secret is stored unviewable.
We’re releasing BOLA vulnerability scanning beginning right now as an Open Beta for all API Defend clients, and are engaged on future API menace scans for future launch. Through the Cloudflare API, you may set off scans, handle configuration, and retrieve outcomes programmatically to combine straight into your CI/CD pipelines or safety dashboards. For API Defend Clients: test the developer docs to start out scanning your endpoints for BOLA vulnerabilities right now.
We’re beginning with BOLA vulnerabilities as a result of they’re the toughest API vulnerability to resolve and the best danger for our clients. Nevertheless, this scanning engine is constructed to be extensible.
Within the close to future, we plan to develop the scanner’s capabilities to cowl the most well-liked of the OWASP Net Prime 10 as effectively: traditional net vulnerabilities like SQL injection (SQLi) and cross-site scripting (XSS). To be notified upon launch, join the waitlist right here, and also you’ll be first to be taught after we develop the engine to basic net software vulnerabilities.
