Announcing API Abuse Detection

Why Generic Web Security Isn't Enough for APIs

Traditional protections like Rate Limiting and DDoS Protection operate on clear, binary rules—for example, whether a given IP has exceeded a fixed number of requests. Those tools break down when applied to APIs because the traffic patterns are rarely that simple. A distributed attack might keep any single source under a naive threshold, while a sudden surge in legitimate traffic could push normal users over it.

Bot Management, another common suggestion, has a similar blind spot. It was designed to sort human users from automated actors, often by issuing challenges that humans can pass but bots can't. That distinction doesn't apply to API traffic, where every request is automated. The real problem is separating good automation from bad automation, which requires evaluating the intent behind each request based on circumstantial data alone. This means asking whether a request is using an endpoint for its intended purpose, and whether its behavior is suspicious in context.

To answer those questions, Cloudflare is announcing early access to two new capabilities: API Discovery and API Abuse Detection.

Mapping the Attack Surface First

Before protecting an API, you have to know it exists. Many companies operate thousands of endpoints and admit they can't track them all. The first step, API Discovery, builds that map automatically by simplifying the problem. Large sites have many paths that look different but serve the same function—consider api.example.com/login/237 and api.example.com/login/415. Both direct users to the same login flow, but the customer identifiers in the URLs make them appear as separate endpoints.

The system records the cardinality of each path segment to distinguish static parts from variables. When an endpoint has far more observed variants than a threshold set by unsupervised learning, the varying segment is recognized as a dynamic value. The paths are then "normalized" and collapsed into a single entry like api.example.com/login/*. The result is a clear, consolidated map of API endpoints, their variables, and tokens, revealing an organization's true attack surface—including the endpoints it didn't know it had.

Detecting Abuse Through Volume and Sequence

Once APIs are mapped, detection can begin. The first layer of defense is volumetric anomaly detection, which acts as an adaptive form of rate limiting. Instead of a one-size-fits-all threshold, this approach builds a tailored baseline for each API path. For a sports site, an endpoint like /update-score naturally gets hammered hundreds of times a minute during a game, so its acceptable threshold would be high. But a /reset-password endpoint on the same domain would have a much lower one. If it starts receiving 150 sudden attempts, that pattern strongly suggests an account takeover attack in progress.

That baseline must also account for context. A spike on /update-score during the NBA Finals is expected and shouldn't trigger any action. The system only intervenes when an individual source is abusing an endpoint, not when aggregate traffic legitimately shifts.

The second layer, sequential anomaly detection, tackles a problem volumetric analysis misses: order of requests. Using Markov Chains, the system treats each normalized endpoint as a state and builds a transition matrix mapping which states typically lead to which others. During testing, path normalization reduced roughly 10,000 states to just 60, and Markov Chain analysis assigned probabilities to the transitions between them.

With this model, a standard flow like /login/*/enter → /login/*/verify → /login-successful reads as a legitimate login attempt. But a request arriving directly at /login-successful without the preceding steps is an outlier and gets flagged. The matrix is efficient in practice: most niche transitions are never exercised, and only the common ones need to be stored.

Applying the Same Model to Mobile Apps

This technique is well-suited for mobile app traffic, which behaves differently from web traffic. Apps rely heavily on APIs, and their requests march along at a deliberate pace. They don't offer the navigational freedom of a website, but that limitation becomes a strength. Legitimate users in an app are constrained to predictable sequences of states, which API Abuse Detection can validate since it's already tracking state transitions.

Competing approaches have tried securing mobile apps by embedding SDKs that authenticate the client. Those SDKs are often bulky and difficult to integrate, and they're inherently insecure: because they run client-side, an attacker who extracts the embedded certificate can bypass the protection entirely. They also fail to detect actual abusive behavior, only checking whether the software doing the requesting is legitimate. API Abuse Detection requires no SDK, relies on server-side modeling, and screens for malicious sequences of behavior rather than just client identity. This also helps organizations that work with partners who rotate headers or can't standardize their signals, since the model evaluates intent rather than assuming all partner traffic is safe.

Organizations interested in testing these capabilities can contact their account team for early access.