Availability and abuse
An app that is trivially knocked over, or that lets one caller run up your bill, has a security problem even if no data leaks. This is about limiting what a single client can consume.
Checklist
- Rate limit every endpoint, not just login. Cap how often and how many calls each client (by IP, by account, by key) can make. Unrestricted resource consumption is its own OWASP API risk. Return 429 when exceeded.
- Throttle expensive operations harder. Anything that triggers a model call, an email, a file conversion, a report, or a database scan deserves a tighter limit, because each call costs real money or CPU.
- Cap pagination. A list endpoint must limit how many records it returns per
page.
?limit=1000000should be clamped, not honored. - Cap upload and body size before parsing, and cap the number of concurrent uploads or jobs a user can start.
- Set timeouts and concurrency limits on outbound calls and on request handling, so one slow dependency cannot exhaust your workers.
- Put a CDN or WAF in front for DDoS. A service like Cloudflare absorbs volumetric floods and lets you rate limit and geo-filter at the edge, before traffic reaches your origin. Make sure the origin cannot be reached directly, around the edge (see infrastructure).
- Fail closed and cheap. When a limit is hit or a dependency is down, reject fast with a clear status, rather than queueing work that piles up.
- Watch autoscaling cost. Resource-exhaustion attacks often show up first as a cloud bill, not an outage. Alert on unusual spend and request volume.
How to test
- Fire a burst of requests at each endpoint and confirm you get 429.
- Request a huge page size and a huge upload and confirm both are clamped.
- Confirm your origin IP does not answer app traffic directly, only through the edge.