API Shield expands: schema validation, DLP, open proxy blocking, and certificate revocation
API traffic at Cloudflare's edge grew 300% faster than web traffic last year, and APIs now handle everything from credit card payments to cryptocurrency trades. That growth brings a corresponding rise in data theft attempts targeting APIs, which OWASP lists as a top threat. In response, Cloudflare is expanding its API Shield toolkit with four new capabilities aimed at reducing the impact of data exfiltration attacks.
The new features include general availability of Schema Validation for all Enterprise customers, a managed IP List to block open proxies, finer-grained control over client certificate lifecycle, and a Data Loss Prevention (DLP) solution. Additional API discovery and anomaly detection features are slated for later in the week.
Schema Validation now generally available
Schema Validation, first introduced during the API Shield launch last October, has moved from limited beta to general availability for Enterprise customers. The deployment flow now lives directly in the dashboard under the "API Shield" tab, with plans to incorporate additional capabilities like mTLS and Rate Limiting into the same interface.
Schema Validation operates on a positive security model. Rather than maintaining a list of malicious request characteristics to block, it defines what legitimate API requests must look like and takes action on anything that doesn't conform. The system accepts schemas following the OpenAPI v3 Specification (Swagger), the standard format for defining RESTful interfaces.
Deploying Schema Validation involves uploading a schema file and specifying the hostname and base path of the API to be protected. The UI then presents a review page grouping endpoints into two categories: those protected by the schema and those left unprotected because their definitions were either unsupported or ambiguous. A catch-all rule ensures traffic directed to endpoints not listed in the schema file is not inadvertently blocked.
When requests fail validation, Cloudflare logs them with the source tag "API Shield," and administrators can inspect these events through the Overview page and its GraphQL-powered dashboard. The validation checks the path, path variables, query parameters, headers, and cookies, with options to either log or drop non-compliant traffic.
Data Loss Prevention for egress traffic
Cloudflare's new DLP suite, announced earlier in the week, now extends to identify sensitive data leaving origins in the response phase of HTTP or API requests. The solution inspects response payloads for common patterns of personally identifiable information such as Social Security numbers, plus financial data like credit card numbers and bank details.
The initial release supports logging DLP matches. Planned enhancements include obfuscation and blocking of sensitive data in egress traffic, along with support for custom rules tailored to specific applications. DLP is offered as a managed ruleset that can be enabled through the Firewall Managed Rules tab.
Because DLP integrates into the WAF, it can be deployed either as part of a reverse proxy setup or through Cloudflare for Teams within a Zero Trust configuration. That tight coupling allows organizations to pair data protection controls with access policies governing who can view sensitive information. DLP is currently in beta for selected early adopters.
Managed IP List blocks open proxies
The first Cloudflare-curated managed IP List, "Cloudflare Open Proxies," is now available to all Enterprise plans for use within Firewall Rules. It contains the IP addresses of open SOCKS and HTTP proxies identified by Cloudflare through analysis of traffic at its edge, and can apply to any traffic evaluated by the Firewall, not just API requests.
Cloudflare populates the list by combining open source intelligence with visibility into requests from every publicly routable IP address on the Internet. After verifying proxies, it determines their exit IPs and feeds this reputation data into both its own security systems and the managed list available to customers.
Users can select "Cloudflare Open Proxies" from the IP Lists drop-down in the Firewall rule builder.
Certificate revocation without custom code
mTLS authentication via client certificates provides strong protection against data exfiltration — but only if compromised or stolen devices can be cut off quickly. Previously, customers often built custom revocation solutions using Workers and Workers KV, which demanded significant development effort and did not scale well.
The new managed solution adds "Revoke" and "Restore" buttons to the client certificate tab in the dashboard, along with supporting API calls. Two new Firewall fields are set for every request presenting a certificate: cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_revoked.
This enables flexible policy combinations. A common setup would allow only requests with verified certificates to pass through, while traffic from revoked certificates gets redirected to an exception-handling endpoint. The full lifecycle — issuance, revocation, and restoration — is handled at the edge, removing the need for customers to operate their own public key infrastructure.
Roadmap: analytics, rate limiting, and anomaly detection
Cloudflare has identified three high-priority API Security features based on customer conversations: deeper API analytics, more flexible rate limiting, and anomaly detection.
Current rate limiting is optimized for web traffic with rules based on URLs and request methods. The team is integrating Firewall Rules logic with rate limiting controls, which will allow traffic segmentation using Firewall's expressive rule language. The counting mechanism is also being extended to support rate limiting based on API keys and user IDs.
Attacks targeting APIs often exhibit patterns that traditional bot management does not handle well. Two features announced later in the week will address this: API Discovery, which maps an organization's endpoints to expose its API surface area, and Anomaly Detection, which—combined with mTLS, Schema Validation, and Rate Limiting—is designed to distinguish legitimate API traffic from malicious activity.
