Using the below steps you can use Cloudflare API Shield to identify and address API vulnerabilities.
1. Login to Cloudflare your account. 2. Select the domain you want to configure from the homepage. 3. In the left sidebar, under "Security", select "API Shield". 4. In the "Endpoint Management" tab, click on "+ Add Endpoints" to add the endpoints that you want to configure. You can either add manually, or upload the OpenAPI schema for bulk upload. 5. Wait for a few minutes for the data to populate and then take actions on each endpoint like adding rate limiting. 6. [Optional] You can also add session identifiers to generate rate limiting recommendations.
NOTE: If you do not see the data populated even after adding the endpoints, please ensure that the subdomain you are tracking is NOT DNS only and has Proxied enabled in DNS Management on Cloudflare.
Cloudflare API Shield Questions Teams Ask
API Shield protects the endpoints you register against abuse of the API itself rather than against generic web traffic. Once endpoints are under Endpoint Management, you can see how each one is being called and act on it — rate limiting the ones being hammered, and spotting endpoints receiving traffic you did not expect. That visibility is the point: most API incidents start with an endpoint nobody was watching.
Add them in the Endpoint Management tab under Security, either one at a time or in bulk by uploading your OpenAPI schema. The schema upload is the better route for anything beyond a handful of endpoints, because it keeps the inventory in API Shield matching the inventory your engineers maintain instead of drifting from it.
The usual cause is that the hostname is set to DNS only rather than Proxied. API Shield can only see requests that pass through Cloudflare, so a DNS-only record means the traffic never reaches it. Check Proxied is enabled for that subdomain in DNS Management, then allow a few minutes for data to populate before concluding something else is wrong.
They are optional, but configure them if you want rate limiting recommendations rather than limits you have guessed at. A session identifier lets API Shield attribute requests to a caller, which is what makes a per-session threshold meaningful. Without one you can still rate limit, but you are setting the number from intuition instead of from observed behaviour.
Not on its own. API Shield is one control, and an auditor will want the surrounding evidence: that you maintain an inventory of your APIs, that someone reviews the endpoint data, that limits are set deliberately, and that you act when something anomalous shows up. The tool produces the signal; the review cadence and the records of what you did about it are what gets tested.
