API Abuse Calculator

Work out how long and how cheaply an attacker could scrape an enumerable endpoint, and whether the economics favour them.

About API Abuse Calculator

Rate limits do not stop a scrape, they price it: the elapsed time is the request count divided by the aggregate rate the attacker can buy, and the cost is the price of the identities needed. Comparing that cost with the resale value of the dataset shows whether your controls have made the attack uneconomic or merely slow. Business-logic abuse does not appear in a vulnerability scan — the endpoint works exactly as designed — so the only way to justify pagination limits and anomaly detection is to show what the dataset costs to take.

Formulas

API Abuse

requests = ceil(records ÷ page size); elapsed = requests ÷ (rate limit × identities); attacker cost = identities × cost per identity.

identities: Rotated API keys, accounts or proxy addresses
page size: Records returned by one request

Attacker economics

ROI = (records × value per record − attacker cost) ÷ attacker cost × 100; expected requests before detection = 100 ÷ per-request detection probability.

value per record: What one record is worth resold or abused
detection probability: Chance any single request trips an alert

Worked example

With the default values below, API Abuse Calculator returns Time to Scrape the Dataset of 0.00. Change any input above and every figure here is recalculated in your browser.

Inputs used

Records reachable through the endpointaccepts 1–10,000,000,000 records: 2,000,000 records
Records returned per responseaccepts 1–10,000 records: 100 records
Rate limit per key or addressaccepts 0.01–100,000 req/s: 5 req/s
Keys or proxies the attacker rotatesaccepts 1–10,000,000 identities: 500 identities
Cost per identityaccepts 0–10,000 USD: 0.6 USD
Detection probability per requestaccepts 0–100 %: 0.5 %
Resale or abuse value per recordaccepts 0–10,000 USD: 0.35 USD

Results

Time to Scrape the Dataset: 0.00 hours
Requests Required: 20,000
Attacker Cost: $300.00
Attacker Cost per Record: $0.0001
Attacker Return on Investment: 233,233%
Detection Before Completion: Likely — detection fires after about 200 requests, well before the scrape finishes

Step by step

1Values used
2API Abuse
3Attacker economics
4Time to Scrape the Dataset= 0.00 hours
5Requests Required= 20,000
6Attacker Cost= 300.00
7Attacker Cost per Record= 0.0001
8Attacker Return on Investment= 233,233
9Detection Before Completion= Likely — detection fires after about 200 requests, well before the scrape finishes

Assumptions and limits

The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or compounding frequency into account.
Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is API Abuse calculated?

requests = ceil(records ÷ page size); elapsed = requests ÷ (rate limit × identities); attacker cost = identities × cost per identity. Rate limits do not stop a scrape, they price it: the elapsed time is the request count divided by the aggregate rate the attacker can buy, and the cost is the price of the identities needed. Comparing that cost with the resale value of the dataset shows whether your controls have made the attack uneconomic or merely slow.

Why does API Abuse matter?

Business-logic abuse does not appear in a vulnerability scan — the endpoint works exactly as designed — so the only way to justify pagination limits and anomaly detection is to show what the dataset costs to take.

What values do I need to enter?

This calculator takes 7 inputs: Records reachable through the endpoint, Records returned per response, Rate limit per key or address, Keys or proxies the attacker rotates, Cost per identity, Detection probability per request, Resale or abuse value per record. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

What actually stops enumeration?

Removing the enumerable pattern first: unguessable identifiers, no sequential IDs, and object-level authorisation on every read. After that, cap total records per credential per day rather than requests per second, and alert on breadth of access — an account that has touched ten thousand distinct records is abnormal however slowly it did so.