API4:2023Unrestricted Resource Consumption
Slide 17 of 28
Part 3 · Attack ScenariosSlide 17
Slide 17 · The Pattern
No limit defined. No limit enforced.
Across every scenario, the same missing question was never asked.
The Missing Question

Every one of these attacks succeeded because the API never asked: "Has this client consumed too much of this resource in the current time window?"

Not "is this request valid?" — it was. Not "is the user authenticated?" — they were. Specifically: in the last minute/hour/day, how much has this client used, and should we stop them?

The pattern in each scenario
Venmo — no request rate limit: how many API calls per minute is too many?
Twitter — no lookup rate limit: how many phone→account lookups per hour is too many?
Followers endpoint — no max page size: how many records per response is too many?
AI generation — no per-user limit: how many paid operations per day is too many?
OTP flooding — no rate limit per phone or IP: how many SMS per number per hour is too many?
The fix pattern
Define explicit limits for every resource-consuming endpoint
Rate limit on multiple dimensions: per user, per IP, per target
Cap paginated results: server enforces max, ignores client's larger request
Cost-based quotas on expensive third-party operations
Monitor for anomalous consumption and alert before the damage is done
← Back How do we fix it? →
📄 View sources