---
{
  "title": "Rate limiting and abuse controls",
  "summary": "Design abuse limits around identity, resource cost, bursts, and concurrent work, then verify their effects on both attackers and legitimate users.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Denial of Service",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---
## What it means

Rate limiting bounds how often a caller can perform an operation over a defined interval. Effective limits consider the resource cost and the entity being protected, not only the requesting IP address. It is one component of availability and abuse resistance rather than a complete denial-of-service solution.

## A practical example

An expensive export service limits concurrent jobs per account and total work across the system. A separate login control uses account and source signals so attackers cannot bypass protection simply by spreading requests across many IP addresses.

## What to check

Define units, windows, identities, and failure behavior for each limit. Test bursts, concurrency, shared addresses, retries, and distributed enforcement. Monitor rejected work as well as successful work.

## A common pitfall

A generous request-per-minute limit may still allow a few extremely expensive requests to exhaust resources. IP-only limits can both miss distributed abuse and disrupt shared networks.

## Think it through

Why limit job concurrency as well as request frequency?

**Answer:** Long-running tasks can accumulate even when incoming request rates appear modest, exhausting workers or memory.

## Count the work that matters

Imagine a fictional academy offers a PDF export. One request can create a tiny report or a much larger job depending on the selected data. A simple request counter treats those costs as equivalent even though they can consume very different resources.

Define the protected resource: database work, CPU time, queued jobs, outbound messages, or another constrained operation. A useful limit may combine frequency, concurrency, and per-job bounds rather than assuming one requests-per-minute value answers every risk.

## Choose the identity deliberately

Suppose many learners share a classroom's public address. A strict IP-only limit can penalize the whole group when one learner performs a legitimate burst. Conversely, distributed abuse can spread requests across addresses and avoid a source-only threshold.

Account, session, device, source, and system-wide signals have different limitations. The service needs an explicit model for what is counted and how it handles anonymous or unauthenticated requests without creating an easy bypass.

## Retries can amplify an outage

When a service rejects work, clients may retry. If every client retries immediately, a protective limit can interact with the client behavior and increase congestion. Document the response and expected retry strategy, including how queued or long-running operations are handled.

For the export feature, distinguish accepting a job from finishing it. Prevent duplicate creation where appropriate and let a learner understand the existing job's status instead of submitting another expensive request blindly.

For an authorized exercise, define a small export budget and simulate a burst, several simultaneous jobs, and many users behind one address. Measure useful completion and rejected work without load-testing a real public service. Explain which limit handles each case and which abuse remains possible. The goal is protecting availability with a predictable user experience rather than selecting an impressive-looking threshold.

## Related concepts

- [[denial-of-service]]
- [[availability]]
- [[logs-and-telemetry]]