Cloudflare’s 2024 API Security Report: Key Findings from Real Traffic Data

APIs now account for more than half of the dynamic traffic flowing across Cloudflare’s network, yet many organizations still struggle to understand exactly what they’re exposing. Cloudflare’s inaugural API Security Report for 2024, based on observed network traffic rather than user surveys, highlights a persistent blind spot: even teams that believe they have a handle on their API footprint often don’t.

The central finding is that nearly a third of API endpoints are effectively “shadow” assets. In testing, Cloudflare’s machine learning-based API discovery—which analyzes all HTTP requests rather than just those flagged by customer configuration—uncovered an average of 30.7% more API endpoints than session-based identification methods. For teams relying solely on developer reports or manual tracking, that means a substantial portion of their public-facing APIs may be operating without proper security oversight.

Why API inventories fall short

APIs are the underlying plumbing for most modern web and mobile applications, quietly enabling everything from authentication to media delivery. End users rarely know they’re interacting with a third-party API at all. That convenience creates a security challenge: developers routinely stand up internet-facing APIs to support their applications, but if those endpoints aren’t documented and routed to the security team, they become shadow APIs—live in production but invisible to defenders.

Traditional approaches to inventorying APIs have notable gaps. Asking developers for a list of endpoints produces results that go stale with the next release. Tracking codebase changes misses legacy applications that no longer receive updates but still handle production traffic. OpenAPI schema files are a useful starting point for teams outside the Cloudflare ecosystem—schemas in OpenAPI v3 format can be parsed to extract endpoints—but unless that process has been in place since the start of development, the resulting inventory will be incomplete.

Rate limiting: response codes and rule design matter

Rate limiting remains a fundamental tool for curbing API abuse, yet the details of implementation can undermine its effectiveness. Cloudflare’s own traffic data shows that nearly 52% of 4xx and 5xx error responses from APIs use HTTP 429 (Too Many Requests), as opposed to alternatives like HTTP 403 (Forbidden).

Both response codes carry trade-offs. A 403 is also emitted by other security tools, making it difficult to attribute blocks to a specific control during an attack. A 429, on the other hand, tells an attacker precisely when they’ve hit a limit, allowing them to surf just below the threshold or distribute requests across more clients to evade it.

The logic of the limit itself is equally important. Cloudflare recommends basing rate limits on a session identifier rather than IP address whenever possible, since shared IP space frequently produces false positives. IP address or IP plus JA3 fingerprint should be a fallback only when session IDs are unavailable. To help customers find the right thresholds, Cloudflare’s API Gateway computes session request statistics across all traffic and derives recommended per-endpoint limits from the statistical distribution—accounting for p50, p90, and p99 request rates, along with a confidence score that improves as more session data is collected. The recommended value is not simply the p-level itself; the variance of the distribution informs the final threshold.

APIs face the same web threats—plus authorization blind spots

API requests are just as vulnerable to standard web application attacks as any other HTTP traffic. A request body can be passed directly into a database query, making SQL injection a live threat for APIs. Cloudflare’s WAF managed rules data for API traffic shows that HTTP anomaly attacks were the most common vector, with injection attacks ranking second.

Data on other attack categories is limited by the very problem it describes. Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) occur when an API fails to verify that the requester is entitled to the data or function they’re accessing. These attacks are difficult to track because a successful attack implies the permission structure is either absent or not enforced—a catch-22 for defenders who would need that structure to identify abuse. Cloudflare plans to address this gap with future API Gateway features that will use traffic norms to suggest security policies targeting BOLA and BFLA.

Until fine-grained authorization is available, Cloudflare recommends four defensive practices:

  • Enforce authentication on every publicly accessible API unless there is a business-approved exception, using options like mTLS or JSON Web Tokens.
  • Rate limit API requests to slow down potential attackers.
  • Monitor and block abnormal volumes of sensitive data leaving the API.
  • Detect and block attackers who skip legitimate sequences of API requests.

API traffic follows human behavior

APIs are no longer just the domain of automated machine-to-machine batch jobs. They drive consumer applications that people use throughout the day, and the traffic patterns reflect it. Worldwide API traffic data shows clear peaks during online shopping events like Black Friday and Cyber Monday, with noticeable drops on Christmas and New Year’s days when people are offline spending time with family. The pattern closely mirrors general HTTP traffic trends—evidence that API usage is now intertwined with everyday human activity.

Cloudflare outlines four high-level strategies for organizations seeking to improve their API security posture:

  1. Manage API development, visibility, performance, and security from a unified control plane that maintains an up-to-date inventory.
  2. Deploy security tools that use machine learning to reduce the burden on human security teams.
  3. Apply a positive security model to APIs, where known-good requests are allowed and everything else is blocked.
  4. Continuously assess and raise the organization’s API security maturity level.

Positive and negative security models are complementary approaches. Negative models, like a traditional WAF, scan for known attack signatures. Positive models are a better fit for the structured nature of APIs: schema validation and authentication checks can enforce a strict allowlist. The most mature organizations combine both, using a WAF for known threats and API schema validation to reject anything else.

API maturity itself develops in stages. Novice teams start with any API inventory, however incomplete. More mature teams move toward accuracy and automatic updates. At the highest level, teams enforce a positive security model with schema validation, authentication checks, and behavioral abuse detection.

Predictions for 2024 and beyond

The report closes with four predictions for the coming year. First, increased loss of control and complexity: 73% of surveyed practitioners said security requirements interfere with their productivity, and sprawling applications with inaccurate inventories will only widen that gap. Second, easier access to AI will lead to more API risks, both through vulnerabilities in AI model APIs and developers shipping insecure, AI-generated code—a Forrester prediction cited in the report expects at least three data breaches in 2024 to be publicly blamed on AI-generated code without proper guardrails. Third, business logic-based fraud attacks will increase, as professional fraudsters run their operations with cost-efficient botnets. Fourth, governance will grow, as the first version of PCI DSS that directly addresses API security takes effect in March 2024.