Even when individual requests are secure, APIs can be abused through volume and frequency. Attackers may perform credential stuffing, brute-force attacks, scraping, or automated data extraction at scale. Rate limiting and throttling controls help protect APIs, and testers must verify that these defences behave correctly.
Rate Limiting, Throttling, and Quotas
Rate limiting restricts how many requests a client can make in a given time window. Throttling may slow responses after certain thresholds, while quotas cap total usage over longer periods. APIs often communicate these limits through headers and respond with status codes like 429 when limits are exceeded.
# Example: probing rate limits with a simple loop
for i in {1..50}; do
curl -s -o /dev/null -w "%{http_code}
" "https://api.example.com/v1/login" || break
sleep 0.2
doneAbuse scenarios also include patterns like rapidly iterating over resource IDs, scraping large result sets, or sending many concurrent requests. Tests should explore how the API responds and whether monitoring and alerting detect these patterns.
Designing Abuse-Case Tests
Create scenarios that simulate repeated login attempts, rapid paging through data, or high-frequency access from a single client. Verify that limits activate, responses degrade gracefully, and legitimate users are not excessively impacted. Also check that logs and metrics capture these events for investigation.
Common Mistakes
Mistake 1 — Assuming rate limiting is automatically configured everywhere
Often, only some endpoints are protected.
❌ Wrong: Never testing rate limiting on login, search, or data export APIs.
✅ Correct: Identify high-risk endpoints and verify protection explicitly.
Mistake 2 — Treating all 429 responses as test failures
Sometimes, hitting a limit is exactly the intended behaviour.
❌ Wrong: Marking tests as failed when rate limiting works as designed.
✅ Correct: Write tests that expect and assert on 429 or throttling responses.