API Hacking: Rate Limiting and Resource Consumption
Not every finding is SQLi. Sometimes the app lets you trigger a thousand emails, resize images on the server, or brute-force an OTP because nobody capped the endpoint.
Resource consumption issues sit awkwardly between security and reliability, but they're in scope on plenty of programs—especially when bills spike or small users get locked out.
Resource abuse findings land better when you translate attempts into dollars, queue depth, or support tickets—not abstract 'could spam' language.
Signals during normal testing
Watch for 429s that never arrive, limits that reset too generously, and per-IP caps that ignore authenticated abuse. Background jobs triggered synchronously are red flags.
File uploads, search, and report generation endpoints deserve gentle probing—not floods.
What responsible validation looks like
On authorized engagements, use small bursts with client approval. Measure response times and error handling; note missing `Retry-After` headers.
Compare limits across free vs paid tiers
Check password reset and invite flows
Document business impact in dollars or SLA terms when possible
Defensive patterns
Layer limits: global, per-user, per-route. Tie expensive work to queues. Monitor anomaly detection on auth and checkout paths.
Denial-of-service isn't a flex. Report consumption issues with restraint and evidence sized to the scope agreement.
If the program forbids load testing, respect that and describe the theoretical risk instead.
Shared infrastructure pain
One abusive endpoint can spike DB CPU for everyone—note whether limits are per-IP only on authenticated routes behind NAT.
Report whether errors fail open or closed: silent drops vs queued jobs matter to ops teams.
Business-aware thresholds
Align rate limits with pricing tiers—free users capped tightly, enterprise contracts documented separately.
Expensive endpoints should return 429 with backoff hints, not 500 when overloaded.
Include queue depth metrics in reports when sync endpoints block workers.
Worth reading next
Race Conditions in Web Apps: Limit Checks and TOCTOU Bugs
API Hacking: OAuth and SAML Security Notes
Business Logic Flaws and Broken Access Control
Comments