API abuse: the endpoint works exactly as intended

A flood is about quantity of the same thing. Abuse is often about the shape of the interaction.

Interfaces built for programs are more generous than pages built for people: they return structured data, they accept parameters that select what to return, and they are designed to be called repeatedly. Each of those properties is useful and each of them is also a lever. A call that returns one record can be made many times to return everything, and a parameter that selects a page of results can select a much larger one.

The consequence is that abuse frequently arrives at rates that would never alarm anyone, because the lever per call is high enough that volume is unnecessary.

Resource abuse. Calling an expensive endpoint often enough to exhaust what is behind it: a search, a report, an operation that fans out into several internal calls. This is the form closest to a flood and the one limits address directly.

Data extraction. Retrieving far more than any single user needs, one legitimate response at a time. Nothing in any individual call is wrong; the total is the problem, and totals are not what most defences measure.

Logic abuse. Using the sequence rather than the volume: repeating an operation that was meant to happen once, taking a step out of order, or exploiting the gap between two calls that were assumed to be adjacent. Rates here can be trivially low.

The third form is where filtering helps least and where the actual fix belongs to whoever designed the endpoint.

Four properties, and none is decisive alone.

Breadth against depth. Real clients look at what concerns them. Access that walks systematically across identifiers or ranges is a different behaviour from access that returns to the same few.

Absence of the rest of the application. Interfaces are usually called alongside something else: a session, an interface, a workflow. Calls arriving without any of that context are automation, which is not automatically abuse but is worth knowing.

Timing that no person produces. Even intervals, or bursts arriving faster than an interface could reasonably drive.

Cost per client wildly out of line. The most reliable signal available, because it does not depend on guessing intent: a client consuming far more work than any plausible user is a fact rather than an inference.

Filtering is often applied to problems it cannot solve.

If an endpoint returns records belonging to whoever asks, the defect is authorisation, and no rate limit repairs it: a limit slows extraction without preventing it. If an operation can be replayed to produce an effect twice, the defect is in the operation, and limiting how fast it can be replayed leaves it replayable.

The classes of flaw behind these are documented in the material on application security rules, and that is the right place for them. What belongs on this page is the traffic-side answer, which is narrower and honest about its narrowness.

Four measures, and the first two do most of the work.

Limit per endpoint and per client, weighted by cost. A uniform limit across an interface either throttles cheap calls needlessly or leaves expensive ones open. The general approach to designing such limits belongs with the material on rate limiting.

Bound what a single call may return. Maximum page sizes and ranges turn extraction into something that needs many calls, which is what limits can then see.

Require identity for anything expensive. Authenticated access ties consumption to an account rather than to an address, which survives distribution across many sources, and it makes revocation possible.

Watch totals per account, not just rates. Extraction is a sum, not a rate. A client whose weekly total is unlike every other client is visible in a way that per-minute counters never show.

What does not help on its own: blocking by address, since interfaces are called from infrastructure rather than from browsers, and matching request content, since the content is correct.

Every measure here can break an integration that someone is paying for.

Partner systems and internal automation look exactly like abuse: no browser, no session, even timing, high volume. Limits applied without knowing who legitimately calls you produce a failure that is invisible on your side and highly visible on theirs, often arriving as a support ticket days later.

Two things reduce the risk. Know which clients are expected before enforcing anything, which usually means issuing them identity instead of guessing from addresses. And prefer measures that slow rather than refuse, because a slowed integration retries and a blocked one fails.

Bridge WAF inspects requests before they reach your origin and applies rate limiting per domain, which addresses the volume side. What it does not do is repair an endpoint that returns data to whoever asks, or an operation that can be replayed for effect. Those are application defects, and any product claiming to fix them from outside is describing something else. See what the platform offers at Bridge CDN.