API Shield

Every endpoint found. Every gap named.

Tap an operation to see its live posture and the risk labels Cloudflare raised against it.

API INVENTORY · 6 OPERATIONSCLOUDFLARE API SHIELDSchemaJWTmTLSRateBotDatagapn/aPOST/api/v1/auth/login42 req/s4/4 · COVEREDSchemaJWTmTLSRateBotDatacf-log-inGET/api/v1/products380 req/s4/4 · COVEREDSchemaJWTmTLSRateBotDatacf-contentGET/api/v1/users/{id}24 req/s2 GAPSSchemaJWTmTLSRateBotDatacf-risk-bola-enumerationcf-risk-sensitivePOST/api/v1/ai/chat9 req/s5/5 · COVEREDSchemaJWTmTLSRateBotDatacf-llmGET/api/v0/reports/export2 req/s4 GAPSSchemaJWTmTLSRateBotDatacf-risk-missing-schemacf-risk-zombiePOST/api/v1/webhooks/partner12 req/s4/4 · COVEREDSchemaJWTmTLSRateBotDatapartnerPosture scan runs every 24 hours4 open risk labels across the inventory
GET

Operation 3 of 6 · 24 req/s

/api/v1/users/{id}

Sessions are walking the ID space and the responses carry personal data. Needs a session-keyed limit before anything else.

cf-risk-bola-enumerationcf-risk-sensitive

Schema ✓

Schema Validation 2.0 checks requests against your OpenAPI 3.0 definition. Action is set per operation: none, log, or block.

JWT ✓

JWT validation verifies the token signature and claims at the edge, before the request reaches your code.

mTLS · n/a

Mutual TLS — only clients presenting a certificate from your CA complete the handshake.

Rate · gap

Session-keyed rate limiting, sized from Cloudflare’s per-endpoint volumetric recommendation.

Bot ✓

Bot score and verified-client signals separate real traffic from scripted automation.

Data · gap

Sensitive Data Detection reads the response and flags PII, card numbers, and secrets on the way out.
Plan API Shield deployment View API security checklist

On this page

Who this is for What Cloudflare API Shield helps you find and fix What is actually in API Shield Why API Shield needs careful rollout Our Cloudflare API Shield approach API architecture considerations Cloudflare API controls we use Where the controls fire Sensitive data in responses API protection matrix API Shield rollout model Deployment steps Risks API Shield readiness checklist Deliverables OWASP API Top 10 coverage When Nanosek should help FAQs

Nanosek provides Cloudflare API Shield services for organizations that need to discover, label, assess, protect, and operate APIs on Cloudflare. The service covers API Discovery and the Web Assets operation inventory, session identifier design, schema learning and Schema Validation 2.0, JWT validation, mTLS and client certificate lifecycle, GraphQL malicious query protection, Sequence Analytics and sequence mitigation, volumetric abuse detection and session-keyed rate limiting, authentication posture, BOLA vulnerability detection, Sensitive Data Detection on API responses, endpoint labeling, Logpush and Security Analytics, staged rollout, false-positive tuning, and managed Cloudflare operations.

Topics: cloudflare, api shield, api security, web assets, schema validation, jwt validation, mtls, api discovery

Machine-readable context: /ai-index.json

Who this is for

Security, platform, application, API, SaaS, mobile, e-commerce, and enterprise teams responsible for public, partner, or internal APIs.
Organizations using Cloudflare that need an accurate API inventory before they can validate schemas, enforce tokens, or scope rate limits.
Teams that already have API Shield findings sitting in the dashboard and need someone to work the cf-risk labels to closure safely.

What Cloudflare API Shield helps you find and fix

Shadow and undocumented APIs

API Discovery runs two models in parallel, one keyed on session identifiers and one machine-learning based that also sees unauthenticated paths. Both feed the Web Assets inventory, where variable path segments collapse into a single operation.

Sensitive data in API responses

Sensitive Data Detection reads response bodies for personal, financial, and secret data. API Shield then labels the operation cf-risk-sensitive, which turns a suspicion into a worklist.

Sensitive data reachable without auth

An operation carrying cf-risk-sensitive alongside cf-risk-missing-auth or cf-risk-mixed-auth is returning regulated data to callers who never authenticated. This intersection is the highest-value finding API Shield produces.

Broken object level authorization

BOLA detection watches for sessions enumerating far more objects than the baseline, and for parameters duplicated into unexpected locations. Both surface as cf-risk labels with exportable attacker fingerprints.

Zombie and legacy endpoints

Saved operations with no traffic for 32 days pick up cf-risk-zombie. Old versions that nobody owns are usually the ones with no schema, no token check, and no rate limit.

Schema drift

Schema learning builds a schema from real traffic. Where a learned schema exists but nothing is enforced, the operation is labeled cf-risk-missing-schema so the gap is visible rather than assumed.

Weak or inconsistent authentication

Authentication Posture compares successful requests against the configured session identifier and separates endpoints where nobody authenticates from endpoints where only some callers do.

Credential stuffing and token abuse

Login and token operations need bot signals, session-keyed rate limits, and Turnstile where a human check is appropriate, with false positives reviewed before anything blocks.

Scraping and volumetric abuse

Volumetric Abuse Detection builds a per-operation, per-session baseline and recommends a rate limit with p50, p90, and p99 context, rather than guessing a number per IP.

Expensive and AI-backed endpoints

LLM-backed operations are labeled cf-llm and cost real money per call. The limit on those is driven by spend as much as by abuse.

Business logic abuse

Sequence Analytics shows the order real sessions call operations in, which is how you spot callers that reach a checkout or transfer step without passing through the steps before it.

Enforcement that breaks working clients

Schema validation, JWT rules, mTLS, and rate limits can all break legitimate traffic. Every control we deploy starts in a mode that logs before it blocks.

What is actually in API Shield

Cloudflare groups API Shield into discovery, posture, and runtime protection. The availability column matters as much as the feature list: only a few pieces are on every plan, most of the suite is an Enterprise add-on, and Sensitive Data Detection is billed separately again. We confirm your entitlements before designing around anything.

1

Discovery and management

Build an inventory you trust before you enforce anything against it.

  • API Discovery

    Enterprise

    Finds operations from live traffic using both a session-identifier model and a machine-learning model, so unauthenticated paths are not missed.

  • Web Assets inventory

    All plans

    The operation inventory itself. An operation is a method, hostname pattern, and path pattern, promoted through candidate and shadow states to full.

  • Session identifiers

    Enterprise

    A header, cookie, or JWT claim that identifies the caller. Discovery, sequences, rate recommendations, and auth posture all depend on it.

  • Schema learning

    API Shield

    Builds an OpenAPI 3.0 schema from real traffic on full operations, using statistical tests so it does not over-constrain.

  • Endpoint labeling

    All customers

    Managed labels such as cf-log-in, cf-purchase, cf-add-payment, and cf-llm, plus your own labels for owner, version, and tier.

  • Sequence Analytics

    API Shield

    Shows the real order sessions call operations in, ranked by how likely those operations are to occur together in that order.

  • Developer portals

    API Shield

    Generates interactive API documentation from saved operations or an uploaded schema, hosted on Cloudflare Pages.

  • API Routing

    Open beta

    Routes matched operations to a chosen origin from the inventory itself rather than through separate rules.

2

Posture management

A scan runs daily across the inventory and labels what is wrong.

  • Sensitive Data Detection

    Separate add-on

    Reads API response bodies for personal, financial, and secret data and drives the cf-risk-sensitive label. Log only, by design.

  • Authentication Posture

    API Shield

    Raises cf-risk-missing-auth where no successful request carries the session identifier, and cf-risk-mixed-auth where only some do.

  • BOLA vulnerability detection

    Enterprise

    Flags object enumeration and parameter pollution as cf-risk-bola-enumeration and cf-risk-bola-pollution, with exportable session and JA4 fingerprints.

  • Volumetric Abuse Detection

    Enterprise

    Recommends a per-operation rate limit from session behavior, with percentile and confidence context. Applying it needs Advanced Rate Limiting.

  • Zombie endpoint detection

    API Shield

    Applies cf-risk-zombie to saved operations that have seen no traffic for 32 days, which is how forgotten API surface gets found.

  • Anomaly labels

    API Shield

    cf-risk-error-anomaly, cf-risk-latency-anomaly, and cf-risk-size-anomaly flag day-over-day shifts. A size spike on a sensitive operation is worth a look.

  • Missing schema detection

    API Shield

    cf-risk-missing-schema marks operations where a learned schema exists but nothing is actually enforcing it.

  • Vulnerability Scanner

    Open beta

    Actively tests for exploitable BOLA using owner and attacker credentials against your spec. API-driven today, no dashboard yet.

3

Runtime protection

The controls that actually act on a request, in the order they fire.

  • mTLS

    All plans

    Client certificates validated against a CA on your account. Available on every plan with the Cloudflare-managed CA; bringing your own CA is Enterprise.

  • Schema Validation 2.0

    All plans

    Validates path, query, header, and cookie parameters plus JSON bodies against OpenAPI 3.0.x. Classic schema validation is deprecated.

  • JWT validation

    API Shield

    Verifies signature, expiry, and not-before at the edge against your JWKS, and makes claims available to rules and header transforms.

  • GraphQL query protection

    API Shield

    Query size and depth exposed as rule fields. Cloudflare ships no default thresholds, so these are derived from your own traffic.

  • Sequence mitigation

    Closed beta

    Enforces that a session reached an operation through the expected preceding steps. Still a closed beta, so it is planned around rather than assumed.

  • Advanced Rate Limiting

    Add-on

    Session-keyed limits sized from the volumetric recommendation, falling back to IP only where no session identifier exists.

  • WAF custom rules

    All plans

    Where mTLS fields, JWT claims, bot score, JA4, and sequence fields are combined into policy. Runs before API Shield in the request path.

  • Bot Management

    Enterprise

    Bot score and verified-client signals, now including signed agents that identify themselves with Web Bot Auth.

Availability reflects Cloudflare’s published plan documentation and changes over time. Beta features are named as beta because rollout planning depends on it. Confirm current entitlements with your Cloudflare account team before committing to a design.

Why API Shield needs careful rollout

API protection breaks legitimate clients when schema validation, JWT rules, mTLS, or rate limits are switched on without traffic evidence behind them. The failure modes are specific and known: an oversized request body skips validation entirely rather than being blocked, a JWT rule triggers when its expression is false rather than true, CORS preflights carry no token by definition, and a revoked client certificate still satisfies cert_verified unless the rule checks for revocation. We start with discovery and logging, map the real clients, then promote controls one operation at a time.

APIs almost always have undocumented clientsSession identifiers gate most of the suiteMobile apps do not behave like browsersLearned schemas need review before enforcementOpenAPI 3.1 is not supported, only 3.0.xRequest bodies over the plan limit skip validationLoose content types let bodies through unvalidatedThe log action for schema validation is Enterprise onlyUnmatched paths need a fallthrough ruleJWT rules trigger on false, not trueCORS preflight requests carry no tokenRevoked certificates still pass cert_verifiedRate limits must match real business workflowsSensitive Data Detection logs, it never blocksLogs must exist before anything blocks

Our Cloudflare API Shield approach

Phase 1

Entitlements, identifiers, and inventory

  • Confirm which parts of API Shield your plan actually includes, since most of the suite is an Enterprise add-on and Sensitive Data Detection is subscribed separately.
  • Design and configure session identifiers, because API Discovery, Sequence Analytics, rate recommendations, and authentication posture all depend on them.
  • Review discovered operations in Web Assets, promote the real ones to full state, and ignore the noise so the inventory stays trustworthy.
Phase 2

Labeling and risk classification

  • Apply managed and custom labels so every operation has an owner, a version, a client type, and a business tier.
  • Turn on Sensitive Data Detection and review which operations return personal, financial, or secret data, and whether that is intended.
  • Work the cf-risk labels in priority order, starting with sensitive data reachable by unauthenticated callers.
Phase 3

Schema and token design

  • Review learned schemas and any specification you already publish, and decide per operation whether it is ready to validate or needs cleanup first.
  • Design JWT token configurations against your identity provider JWKS, including key rollover, and decide where missing tokens should be ignored rather than treated as non-compliant.
  • Plan mTLS where certificate identity is genuinely the right answer, including issuance, hostname association, revocation checking, and how the certificate reaches your origin.
Phase 4

Policy design in the right order

  • Place controls deliberately across the request path, since WAF custom rules and rate limiting run before API Shield, and WAF Managed Rules run after it.
  • Size rate limits from the volumetric recommendation and the business workflow, keyed on session rather than IP wherever a session identifier exists.
  • Derive GraphQL depth and size thresholds from your own traffic, and add a fallthrough rule for requests that match no saved operation.
Phase 5

Staged enforcement

  • Deploy schema validation and JWT rules in log mode first, then promote per operation once the events show only what you expect.
  • Validate against known clients, mobile builds, partner integrations, and synthetic checks before any action changes to block.
  • Keep a documented rollback for every control, including the zone-wide schema validation override that disables enforcement without losing per-operation configuration.
Phase 6

Operations and tuning

  • Run the daily posture scan as a working queue rather than a dashboard, with new labels triaged, owned, and closed.
  • Configure Logpush, Security Events review, alerting, and per-operation reporting through the Web Assets fields in the GraphQL Analytics API.
  • Keep schemas, labels, and rules aligned with API releases so posture does not decay between engagements.

API architecture considerations

Hostnames, path patterns, methods, versions, and client types, plus which operations are worth promoting to full state and which should be ignored.
Session identifier choice, since a header, cookie, or JWT claim that does not genuinely identify a caller will quietly degrade discovery, sequences, and rate recommendations.
Schema quality and ownership: OpenAPI 3.0.x only, request bodies capped by plan, and a deployment process that updates schemas when the API changes.
Token architecture: JWKS location and rotation, which operations should require a token, and where claims should be forwarded to the origin.
Certificate lifecycle for mTLS: issuance, hostname associations, revocation enforcement in the rule itself, and how client identity reaches the origin safely.
Rule ordering across phases, because a terminal block in a WAF custom rule preempts schema validation, and a schema block preempts WAF Managed Rules.
Response-side exposure: which operations return sensitive data, whether that is intended, and what evidence you keep of it.
Observability: Security Events, Logpush destinations, and the operation and label fields now available in GraphQL Analytics, which is where per-operation alerting is built rather than from a dedicated API Shield notification.

Cloudflare API controls we use

API Discovery

Finds operations from live traffic with both session-identifier and machine-learning models, including unauthenticated paths the session model cannot see.

Web Assets inventory

The operation inventory API Shield acts on. We promote real operations to full state so schema learning and per-operation metrics begin.

Session identifiers

Configured as a header, cookie, or JWT claim. This is the prerequisite most teams have wrong, and most of the posture features depend on it.

Endpoint labeling

Managed labels for behavior and risk, plus custom labels for owner, version, tier, and client type so the inventory can be filtered and reported on.

Sensitive Data Detection

Inspects API response bodies for personal, financial, and secret data and drives the cf-risk-sensitive label. Always log action, no added latency.

Authentication Posture

Separates operations where nobody authenticates from operations where only some callers do, which is where broken access control usually starts.

BOLA vulnerability detection

Flags object enumeration and parameter pollution against the inventory, with session and JA4 fingerprints you can export and act on.

Volumetric Abuse Detection

Produces per-operation, per-session rate limit recommendations with percentile and confidence context instead of a guessed per-IP number.

Schema Validation 2.0

Validates path, query, header, and cookie parameters and JSON bodies against OpenAPI 3.0.x, per operation, with a zone default and a kill switch.

JWT validation

Verifies signature, expiry, and not-before against your JWKS at the edge, and exposes claims to WAF rules, rate limiting, and header transforms.

mTLS and client certificates

Certificate identity for partner, service, IoT, and high-trust clients, enforced in a rule that checks issuer SKI and revocation, not just verification.

GraphQL malicious query protection

Query size and depth as rule fields. Thresholds are derived from your own traffic because Cloudflare ships no defaults here.

Sequence Analytics and mitigation

Shows the real order sessions call operations in, and enforces expected order where the beta is available to you.

Advanced Rate Limiting

Session-keyed limits on login, token, search, export, upload, checkout, and expensive or AI-backed operations.

WAF custom rules

Where mTLS fields, JWT claims, bot score, JA4, geography, and sequence fields become policy. Runs before API Shield, so ordering is deliberate.

Bot Management and Turnstile

Separates real clients from automation, including signed agents that identify themselves, with human verification where it fits the flow.

Origin Rules and Authenticated Origin Pulls

Pins expected origins and proves to your backend that the connection came from Cloudflare rather than around it.

Logpush, Security Events, and GraphQL Analytics

Exports API decisions to your SIEM and supports per-operation reporting through the Web Assets operation and label fields.

Cloudflare Workers

Used where native controls stop short: request enrichment, JWKS refresh, custom validation, routing, and integration logic.

Where the controls fire

API Shield does not sit at the front of the request. It runs in its own rule phase, after your WAF custom rules and rate limiting, and before WAF Managed Rules. That ordering decides which control gets to act first, and it is the reason a rule can look like it stopped working the week API Shield went in. We place controls with the order in mind rather than discovering it during an incident.

Request path

The order is Cloudflare’s documented rule phases, not a diagram convention. Tap a stage.

REQUEST →← RESPONSEClient3 controlsTLS3 controlsWAF rules4 controlsAPI Shield4 controlsManaged3 controlsOrigin3 controlsData check3 controlsResponse3 controls

API Shield enforcement

http_request_api_gateway_late

Schema Validation 2.0 checks the request against your OpenAPI 3.0 definition, JWT validation rules check the token, sequence rules check what the session did before this call, and GraphQL rules check query depth and size. Requests that do not match a saved operation are outside this phase entirely — they need a fallthrough rule.

Schema Validation 2.0JWT validationSequence mitigationGraphQL query limits

Sensitive data in API responses

Most API security work looks at what comes in. The harder question is what goes out: which of your operations return personal, financial, or secret data, whether that was intended, and who can reach them. Cloudflare answers the first part with Sensitive Data Detection, a WAF managed ruleset that reads response bodies and feeds the result straight into your API inventory.

Sensitive data protection on Cloudflare comes in two forms, and an API engagement needs the first: Sensitive Data Detection inspects responses coming out of your own origins, and Data Loss Prevention in Cloudflare One inspects your workforce’s outbound traffic. Nanosek deploys and tunes both — only the first one shows up against your API inventory.

Response inspection

GET /api/v1/users/{id} on its way back to the caller

Out of band · no added latency
HTTP/2 200 OK
content-type: application/json
{
"id": "usr_8842",
"name": "A. Customer",
"tier": "business",
"passport": "5########2"
"card": { "pan": "4### #### #### ####"
"orders": 14,
"integration": {
"provider": "billing",
"key": "sk_live_################"
},
"updated": "2026-08-18T09:14:02Z"
}

Text, HTML, JSON, and XML responses are inspected up to 1 MB, including responses served from cache and responses composed by a Worker. Matched values are never stored.

Detected

·

Personal

Passport number in the user object

·

Financial

Card number returned unmasked

·

Secret

Live API key echoed back to the caller

Then what

The event lands in Security Events with the rule that fired, but never the matched value.

Within a day the posture scan labels the operation cf-risk-sensitive.

Nothing is blocked. The response was already sent, which is exactly why the check costs no latency.

The finding worth acting on first

cf-risk-sensitive + cf-risk-missing-auth = regulated data, no login required

An operation carrying both labels is returning sensitive data to callers who never authenticated. The same applies to cf-risk-mixed-auth, where only some callers do. This intersection is the closest thing API Shield has to an automated finder for the top two entries in the OWASP API Top 10, and it is where we start every engagement that has detection already switched on.

What it does and does not do

Responses only

It reads what your origin sends back. Request-side inspection is a different control, and for AI endpoints that is AI Security for Apps.

Log, never block

Detection happens outside the response path. That is why it adds no latency, and why it can never stop the response it just read.

Three categories

Personal, financial, and secret data, with passport numbers, card numbers, and API keys as Cloudflare’s own examples. There is no custom pattern support.

Tuning is mandatory

Some rules ship switched off to keep false positives down. Turning the ruleset on is the start of the work, not the end of it.

The value is never stored

You learn that an operation returned a card number and which rule matched, not what the number was. Investigation pivots to your own logs.

Separately licensed

Enterprise on the advanced application security plan, with its own subscription. Worth confirming before it is designed into a rollout.

API protection matrix

Login and token APIs

Common risk

Credential stuffing, brute force, token abuse

Recommended Cloudflare approach

Session-keyed rate limits, Bot Management, Turnstile where it fits, JWT rules that exempt token issue and refresh operations

Object read APIs

Common risk

Broken object level authorization and enumeration

Recommended Cloudflare approach

BOLA detection, session-keyed limits, schema validation on path parameters, and Vulnerability Scanner where available

APIs returning personal data

Common risk

Regulated data reachable by the wrong callers

Recommended Cloudflare approach

Sensitive Data Detection, cf-risk-sensitive triage, authentication posture review, and enforcement on anything reachable unauthenticated

Public REST APIs

Common risk

Malformed requests, scraping, high-volume abuse

Recommended Cloudflare approach

Discovery, learned schemas, Schema Validation 2.0, rate limits, and a fallthrough rule for unmatched paths

Partner and service APIs

Common risk

Legitimate automation blocked or over-allowed

Recommended Cloudflare approach

mTLS with issuer and revocation checks, scoped policies, per-partner limits, and explicit exception ownership

Mobile APIs

Common risk

False positives against app-specific behavior

Recommended Cloudflare approach

Client classification, API-specific rules, careful bot policy, and staged enforcement per app release

GraphQL endpoints

Common risk

Expensive queries and abuse concentration

Recommended Cloudflare approach

Depth and size rules derived from your own percentiles, plus limits and logging. Note that only paths ending in /graphql are parsed

AI and LLM-backed APIs

Common risk

Cost abuse, prompt injection, data in prompts and responses

Recommended Cloudflare approach

cf-llm labeling, spend-aware rate limits, AI Security for Apps on the request side, and Sensitive Data Detection on the response

Upload APIs

Common risk

Large payload abuse and malware workflow pressure

Recommended Cloudflare approach

Method-aware controls, size expectations, malicious upload detection, origin capacity review, and monitoring

Export and reporting APIs

Common risk

Bulk data extraction and backend load

Recommended Cloudflare approach

Authentication review, session-keyed limits, bot controls, response-size anomaly monitoring, and business-owner thresholds

Admin APIs

Common risk

Privileged action exposure

Recommended Cloudflare approach

Cloudflare Access or service tokens, mTLS, strict rules, and least-privilege client controls

Webhook receivers

Common risk

Spoofed or replayed events

Recommended Cloudflare approach

Signature validation, mTLS where the sender supports it, rate limits, and Workers or Queues where appropriate

Legacy API versions

Common risk

Unmaintained behavior and missing controls

Recommended Cloudflare approach

cf-risk-zombie triage, separate monitoring, stricter policy, a deprecation plan, and staged migration

API Shield rollout model

From API visibility to enforcement

Rollout stage

Entitlement check

Cloudflare capability

API Shield plans, Sensitive Data Detection subscription

Implementation notes

Establish what is included before designing around it. Most of the suite is an Enterprise add-on and Sensitive Data Detection is billed separately.

Rollout stage

Identify the caller

Cloudflare capability

Session identifiers

Implementation notes

Header, cookie, or JWT claim. Nearly everything downstream degrades without one that genuinely identifies a client.

Rollout stage

Discovery

Cloudflare capability

API Discovery, Web Assets, endpoint labeling

Implementation notes

Promote real operations to full state, label ownership, and ignore the rest so the inventory stays usable.

Rollout stage

Exposure review

Cloudflare capability

Sensitive Data Detection, Authentication Posture, BOLA detection

Implementation notes

Turn on detection before enforcement. Sensitive data on an unauthenticated operation is the first thing to fix.

Rollout stage

Documentation cleanup

Cloudflare capability

Schema learning, OpenAPI review

Implementation notes

Learned schemas need review. OpenAPI 3.0.x only, and request bodies over the plan limit are not validated at all.

Rollout stage

Visibility mode

Cloudflare capability

Log actions, Security Events, Logpush

Implementation notes

Schema validation and JWT rules run in log first. Review the events against known clients before promoting anything.

Rollout stage

Controlled enforcement

Cloudflare capability

Schema Validation 2.0, JWT rules, mTLS rules, rate limits

Implementation notes

Promote per operation and per client group, keeping the zone-wide override available as a rollback.

Rollout stage

Operations

Cloudflare capability

Daily posture scan, alerts, GraphQL Analytics, managed services

Implementation notes

Treat new cf-risk labels as a queue with owners, and keep schemas aligned with API releases.

Cutover checkpoints

  • Plan entitlements are confirmed, including whether Sensitive Data Detection is subscribed.
  • Session identifiers are configured and verified against real authenticated traffic.
  • Known clients, mobile builds, and partner integrations are documented against saved operations.
  • Learned or published schemas are reviewed, and request body size limits are understood per plan.
  • Rollback is defined for every control, including the zone-wide schema validation override.

Validation signals

  • No unexpected increase in API 4xx or 5xx responses after a control is promoted.
  • Security Events show only the matches you expected, with known clients absent from them.
  • Logs carry the operation ID, labels, action, and outcome needed to review a decision later.
  • Synthetic checks and business-critical API journeys continue to pass after each promotion.
  • The count of open cf-risk labels trends down rather than accumulating.

Deployment steps

  1. 01 Confirm plan entitlements, then design and configure session identifiers so the rest of the suite has something to key on.
  2. 02 Review discovered operations in Web Assets, promote the real ones to full state, and label them with owner, version, client type, and tier.
  3. 03 Turn on Sensitive Data Detection and triage cf-risk-sensitive, prioritizing anything that also carries a missing or mixed authentication label.
  4. 04 Work the remaining risk labels: BOLA findings, missing schemas, anomalies, and zombie operations that should be retired rather than protected.
  5. 05 Review learned and published schemas, design JWT token configurations against your JWKS, and plan mTLS where certificate identity is the right answer.
  6. 06 Design rules across the request path deliberately, sizing rate limits from volumetric recommendations and deriving GraphQL thresholds from your own percentiles.
  7. 07 Deploy schema validation and JWT rules in log mode, validate against known clients and synthetic checks, then promote to block per operation.
  8. 08 Operationalize the daily posture scan, Logpush, alerting, per-operation reporting, false-positive handling, and ongoing tuning.

Risks and mitigations

Risk

Schema validation blocks legitimate clients

Mitigation

Review learned schemas, start in log, promote per operation, and keep the zone-wide override available as an immediate rollback.

Risk

Large request bodies silently skip validation

Mitigation

Confirm the per-plan body inspection limit, identify operations that exceed it, and cover them with rules rather than assuming validation applies.

Risk

A permissive content type lets bodies through unchecked

Mitigation

Schema validation inspects JSON bodies. Where a schema allows a broader media range, requests sent under another content type pass without body validation, so we keep media ranges tight and recommend disabling content-type sniffing at the origin.

Risk

Requests to unlisted paths are never evaluated

Mitigation

An operation has to exist in the inventory before schema validation can match it. We deploy a fallthrough rule scoped to your API hostnames so unmatched paths are handled deliberately rather than ignored.

Risk

JWT rules block more than intended

Mitigation

Remember the rule triggers when the expression is false, exempt token issue and refresh operations, and account for CORS preflights carrying no token.

Risk

mTLS rollout disrupts partners

Mitigation

Plan issuance, hostname associations, test windows, and fallback with each partner, and check issuer SKI and revocation in the rule rather than verification alone.

Risk

Revoked certificates keep working

Mitigation

Revocation is not enforced automatically. Rules must test the revoked flag explicitly, and revocation is only checked for the Cloudflare-managed CA.

Risk

Rate limits break normal workflows

Mitigation

Size from the per-operation recommendation and the business process, key on session rather than IP, and deploy low-confidence recommendations in log first.

Risk

Sensitive data findings are mistaken for prevention

Mitigation

Sensitive Data Detection only logs. Treat it as evidence and posture, and fix the exposure at the origin or with an access control in front of it.

Risk

Detection produces false positives

Mitigation

Some detection rules ship disabled to limit noise. Enable what matches your data types and tune rather than turning everything on at once.

Risk

Controls conflict across rule phases

Mitigation

Place rules knowing that custom rules and rate limiting run before API Shield, and managed rules run after it, so a terminal action hides everything downstream.

Risk

Unknown APIs remain exposed

Mitigation

Run discovery continuously, review new operations as a queue, and treat the inventory as something owned rather than generated once.

Risk

Beta features are planned as if generally available

Mitigation

Sequence mitigation is a closed beta and the vulnerability scanner is an API-only open beta. We design a path that works without them and adopts them when available.

Risk

Posture decays after the project ends

Mitigation

Keep schemas, labels, and rules aligned with API releases, and run the daily scan output as an owned queue with review dates.

API Shield readiness checklist

  • Plan entitlements confirmed
  • Sensitive Data Detection subscription confirmed
  • Session identifiers configured
  • API hostnames inventoried
  • Operations promoted to full state
  • Discovery noise triaged and ignored
  • Endpoint labels applied with owners
  • Known clients and mobile builds identified
  • Partner integrations documented
  • Authentication posture reviewed
  • Sensitive operations confirmed as intended
  • BOLA findings triaged
  • Learned schemas reviewed
  • OpenAPI version and body size limits checked
  • JWT token configurations and JWKS rotation planned
  • mTLS issuance and revocation checks defined
  • Rate limits sized from recommendations and workflows
  • GraphQL thresholds derived from real traffic
  • Fallthrough rule scoped to API hostnames
  • Rule phase ordering reviewed
  • Security Events and Logpush visible
  • Synthetic checks prepared
  • Rollback and exception process defined
  • Business owners approve enforcement

Deliverables

  • Entitlement and licensing review
  • Session identifier design
  • API operation inventory in Web Assets
  • Endpoint labeling and ownership map
  • Sensitive data exposure report
  • Authentication posture findings
  • BOLA and abuse findings triage
  • Learned schema review and readiness call per operation
  • Schema Validation 2.0 rollout plan
  • JWT token configuration and rotation design
  • mTLS and certificate lifecycle design
  • Rate limiting design keyed on session
  • GraphQL threshold analysis
  • Rule phase and ordering map
  • Fallthrough and exception design
  • Logpush, alerting, and reporting setup
  • Validation and synthetic test matrix
  • False-positive tuning report
  • Rollback and exception process
  • Managed operations handover

OWASP API Top 10 coverage

API1 Broken object level authorization

Cloudflare capability

BOLA vulnerability detection, Vulnerability Scanner, schema validation on path parameters

What Nanosek does with it

Triage enumeration and pollution findings, export the attacking sessions, and pair with a session-keyed limit while the origin fix is built.

API2 Broken authentication

Cloudflare capability

Authentication Posture, JWT validation, mTLS, Cloudflare Access

What Nanosek does with it

Work cf-risk-missing-auth and cf-risk-mixed-auth to closure, then enforce tokens at the edge with token issue and refresh paths exempted.

API3 Broken object property level authorization

Cloudflare capability

Schema Validation 2.0, Sensitive Data Detection

What Nanosek does with it

Constrain request properties against the schema and use response-side detection to find operations returning more than they should.

API4 Unrestricted resource consumption

Cloudflare capability

Volumetric Abuse Detection, Advanced Rate Limiting, GraphQL query limits

What Nanosek does with it

Size limits from the per-operation recommendation and the business workflow, with AI-backed operations limited on cost as well as volume.

API5 Broken function level authorization

Cloudflare capability

JWT claim rules, WAF custom rules, Cloudflare Access, service tokens

What Nanosek does with it

Separate admin and privileged operations from the general policy rather than letting them inherit website rules.

API6 Unrestricted access to sensitive business flows

Cloudflare capability

Sequence Analytics, sequence mitigation, Bot Management

What Nanosek does with it

Establish the real call order for checkout, transfer, and signup flows, then enforce it where the beta is available.

API7 Server side request forgery

Cloudflare capability

WAF Managed Rules, schema validation on URL-typed parameters

What Nanosek does with it

Constrain parameters that accept URLs at the schema level and keep managed rules in the path behind API Shield.

API8 Security misconfiguration

Cloudflare capability

Web Assets inventory, risk labels, Security Insights

What Nanosek does with it

Use the daily posture scan as the misconfiguration feed, including missing schemas and anomaly labels.

API9 Improper inventory management

Cloudflare capability

API Discovery, endpoint labeling, zombie detection

What Nanosek does with it

Keep the inventory current, label ownership, and retire cf-risk-zombie operations rather than leaving them exposed.

API10 Unsafe consumption of third-party APIs

Cloudflare capability

Workers, Origin Rules, Logpush

What Nanosek does with it

Largely an origin-side concern, but outbound calls and webhook receivers are brought under the same validation and logging discipline.

When Nanosek should help

You have public, partner, mobile, internal, or AI-backed APIs behind Cloudflare.
You need an accurate API inventory before you can enforce anything against it.
You have API Shield findings sitting in the dashboard that nobody has worked through.
You need to know which APIs return personal or financial data, and to whom.
You want schema validation or JWT validation but are unsure your definitions and token setup are ready.
You need mTLS for partner or service clients and want the certificate lifecycle designed properly.
You are still on Classic schema validation and need to move to Schema Validation 2.0 before it stops being an option.
You are seeing scraping, credential stuffing, object enumeration, or expensive endpoint pressure.
You want ongoing Cloudflare API security tuning and managed operations rather than a one-off project.

Frequently asked questions

What is Cloudflare API Shield?
API Shield is Cloudflare’s set of API-specific capabilities, grouped into discovery and management, posture management, and runtime protection. In practice that means finding your API operations, labeling what is risky about them, and enforcing schema validation, token validation, mTLS, sequence rules, and rate limits at the edge. Nanosek designs, deploys, and operates those controls around your real traffic.
Where is API Shield in the Cloudflare dashboard now?
It is no longer a single nav item. The API inventory lives under Security and Web Assets, session identifiers and token configurations sit under Security Settings filtered by API abuse, and rules are created under Security rules. If you are following an older runbook that points at an API Shield menu, that is why it does not match.
Do we need an Enterprise plan?
For the full suite, yes. Endpoint management and schema validation are available on every plan, and mTLS with the Cloudflare-managed CA is too. API Discovery, JWT validation, sequence analytics, volumetric abuse detection, BOLA detection, and the rest require Enterprise with an API Shield subscription. Sensitive Data Detection is subscribed separately again. We confirm entitlements before designing anything around them.
What is Sensitive Data Detection, and can it stop a leak?
It is a Cloudflare WAF managed ruleset that reads API response bodies and flags personal, financial, and secret data. It cannot block, and that is by design: detection happens outside the response path, which is why it adds no latency, and you cannot block a response that has already been sent. Treat it as visibility and evidence. The fix goes at the origin, or in an access control in front of the operation.
We call this sensitive data protection. Which Cloudflare product is it?
Two products cover it, and which one you need depends on the direction of the traffic. Sensitive Data Detection is the WAF managed ruleset that inspects responses coming out of your origins, and it is the one wired into your API inventory. Data Loss Prevention in Cloudflare One inspects your own workforce traffic through Gateway, and unlike detection it can block. Most API engagements start with the first; the second is usually a separate Zero Trust conversation.
What does cf-risk-sensitive actually tell us?
That sensitive data was detected in responses from that operation recently. API Shield rescans the inventory every day against a rolling window of WAF events, so the label appears within about a day and clears once the exposure stops. The finding worth acting on first is an operation carrying cf-risk-sensitive alongside cf-risk-missing-auth or cf-risk-mixed-auth, because that means regulated data is reachable without authenticating.
Do we need OpenAPI schemas?
For schema validation, yes, and only OpenAPI 3.0.x is supported. If you do not have usable definitions, schema learning can build one from real traffic on operations promoted to full state. Either way we review the schema before enforcing it, and check the per-plan request body limit, because bodies over that limit are not validated at all rather than being blocked.
How does JWT validation differ from what our API already does?
Cloudflare verifies the signature, expiry, and not-before against your JWKS before the request reaches your code, and makes the claims available to rules, rate limiting, and header transforms. It complements your application checks rather than replacing them. The main deployment traps are that the rule triggers when its expression is false, and that CORS preflight requests carry no token by definition.
When should we use mTLS?
For partner, service-to-service, IoT, and high-trust clients where certificate identity is genuinely appropriate. It is available on every plan with the Cloudflare-managed CA, and bringing your own CA is Enterprise. Enabling it validates the certificate but does not block anything by itself, so the rule matters, and it should check the issuer and the revoked flag rather than verification alone.
Can API Shield protect GraphQL and AI endpoints?
Yes, with caveats worth knowing up front. GraphQL query size and depth are exposed as rule fields with no default thresholds, so those come from your own traffic, and only paths ending in /graphql are parsed. AI-backed operations get labeled cf-llm, and are usually limited on cost as much as abuse, with request-side prompt inspection handled by AI Security for Apps and response-side exposure by Sensitive Data Detection.
Can API Shield break legitimate traffic?
Yes, if it is switched on without evidence. That is the whole reason for the staged approach: discovery and labeling first, detection before enforcement, log actions before block actions, validation against real clients and synthetic checks, and a documented rollback for every control.
Can Nanosek help after API Shield is deployed?
Yes. Managed operations cover the daily posture queue, schema and label upkeep as the API changes, rate limit and rule tuning, JWKS and certificate rotation, Logpush and alert review, incident support, and reporting.

Turn API Shield findings into enforced protection

Nanosek takes you from an incomplete API inventory to controls you can actually leave switched on: discovery, labeling, sensitive data visibility, schema and token validation, mTLS, session-keyed limits, and managed operations after go-live.

Talk to Nanosek View Cloudflare managed services
Ready to talk?

Deliver Cloudflare without surprises.

Whether you're migrating, hardening, or operating Cloudflare — Nanosek brings authorized MSP & ASDP delivery, rollback-ready cutovers, and managed operations after launch.

Talk to Nanosek Run readiness assessment