API Shield: Cloudflare applies positive security to APIs

APIs now carry half of all traffic across Cloudflare’s network — some 18 million requests per second — and the majority of those requests are blocked as malicious. The attack surface is only widening: Gartner estimates that by 2021, 90% of web-enabled applications will expose more attack surface through APIs than through their UI, up from 40% in 2019. By 2022, the firm predicts API abuse will become the most frequent attack vector causing data breaches.

To counter that trend, Cloudflare has launched API Shield, a free offering on all plans that applies a positive security model to API traffic. The two core capabilities are strong identity through mutual TLS (client certificates) and strict schema-based validation of request contents. The protections extend to gRPC-based APIs using binary formats such as protocol buffers, not just JSON-based REST endpoints.

A positive security model

Traditional WAFs work from a negative security model: allow everything except known-bad requests from suspicious IPs, ASNs, countries, or with attack signatures such as SQL injection patterns. A positive security model inverts this — it denies everything except traffic that matches known identities and behavior. For APIs, that approach eliminates credential stuffing and automated scanning noise more directly than chasing bad actors with rules.

The root of a positive model is strong authentication. Mutual TLS requires clients to present a certificate, making password reuse and shared credentials irrelevant. Cloudflare has simplified certificate issuance with a fully hosted private PKI: rather than operating your own CA, you generate client certificates from the Cloudflare dashboard or via API calls. It’s the same approach the company took with Universal SSL in 2014, but applied to client-side identity.

Certificates separate legitimate clients from attackers, but they’re not infallible — certificates can be extracted from devices. That’s where schema validation comes in. By validating API requests — query parameters and the POST body — against a schema defining what the endpoint expects, Cloudflare blocks extraneous inputs at the edge before they reach the origin. Schema validation is currently in closed beta for JSON payloads, with gRPC/protocol buffer support planned. Customers can join the beta by opening a support ticket with the subject "API Schema Validation Beta".

The demonstration setup

Cloudflare demonstrates the offering with an IoT temperature monitoring system: a Raspberry Pi 3 Model B+ with an infrared temperature sensor sends POST requests to a Cloudflare-protected API; an iOS app displays the temperatures with GET requests. The API itself runs on Cloudflare Workers and Workers KV, but any internet-accessible endpoint would work.

1. API configuration

The demo API is a simple Worker built by adapting code from the To-Do List tutorial. It stores temperatures in Workers KV, keyed by source IP address — though a client certificate attribute such as a fingerprint could replace that key. POST requests save a temperature reading and timestamp; GET requests return the five most recent readings.

2. Client certificate issuance

Certificates can be created through the SSL/TLS → Client Certificates tab of the Cloudflare Dashboard, but for automation you’ll likely generate your own private keys and certificate signing requests (CSRs), then request signatures via the Cloudflare API. Cloudflare’s PKI toolkit CFSSL creates the bootstrap certificate for the iOS app and the certificate for the IoT device; the CSRs are signed by a private CA issued for your zone.

3. Creating the rule

With certificates issued, the next step is configuring hostnames to require client certificates and creating the API Shield rule. This points Cloudflare at the domains that must prompt for a certificate during the TLS handshake.

4. IoT device communication

On the device, the private key and certificate are copied to /etc/ssl/private/sensor-key.pem and /etc/ssl/certs/sensor.pem. When the script connects to the API endpoint, Cloudflare requests a client certificate; the script presents sensor.pem and proves possession of the private key to complete the handshake. Without a valid certificate — or with extra fields in the payload — the request is rejected by schema validation. Valid requests successfully reach the API.

5. iOS application communication

For the mobile side, the bootstrap certificate and key are packaged as a binary PKCS#12 (.pfx) file. In the demo the file is embedded directly into the application bundle; in production, a bootstrap certificate should be used only with user credentials to obtain a unique per-user certificate from an API endpoint, with MDM distribution for enterprise users.

In Xcode, the .pfx file is added to the project with File → Add Files To, ensuring "Add to target" is selected. A walkthrough of using a PKCS#11 class with URLSessionDelegate shows how to modify the app to complete mutual TLS when connecting to an API that requires it.

Roadmap

Cloudflare plans several API Shield expansions: support for importing your own CA certificates for customers running their own PKI (already available today as part of Cloudflare Access), general availability for schema validation after the beta, and further API security capabilities with deeper analytics for API traffic monitoring.