July 28, 2026
OWASP API #4 — Unrestricted Resource Consumption: When APIs Don’t Know When to Say “Enough”
Imagine an e-commerce website that allows users to search for products.
By Narmadha
2 min read
A normal user searches a few times before making a purchase.
An attacker, however, automates millions of search requests every day. Even though each request is legitimate, the massive volume consumes server resources, slows down the application, and may expose sensitive information through automated data harvesting.
This is exactly what Unrestricted Resource Consumption is about.
What is Unrestricted Resource Consumption?
Unrestricted Resource Consumption occurs when an API fails to limit how many requests or resources a user can consume.
Instead of exploiting a software bug, attackers abuse legitimate API functionality at a massive scale.
Common examples include:
- Missing or weak rate limiting
- Unlimited API requests
- Large file uploads
- Excessive API responses
- Long-running requests
- Unlimited memory or CPU consumption
Real-World Breach: Trello
Trello had a public API that allowed users to check whether an email address belonged to a Trello account.
A researcher discovered that this endpoint could be queried without authentication.
Attackers collected 500 million email addresses from previous data breaches and sent millions of requests to the API.
The API responded with profile information for valid users.
Although Trello had rate limiting, attackers bypassed it by distributing requests across multiple IP addresses and slowly harvesting data over time.
How Attackers Exploit It
Attackers don't always crash an application.
Sometimes they simply automate legitimate requests until valuable information is collected.
Typical attack flow:
- Discover public API endpoints.
- Write a script to automate requests.
- Send thousands or millions of requests.
- Rotate IP addresses or use proxy networks.
- Harvest exposed data while staying below rate-limit thresholds.
How Pentesters Should Test
- Verify whether rate limiting is implemented on sensitive endpoints.
- Test login, registration, password reset, and search APIs for brute-force protection.
- Send repeated requests using Burp Intruder or Turbo Intruder.
- Check whether rate limits apply per IP, per user, or per API key.
- Test if changing IP addresses bypasses rate limits.
- Verify maximum upload size and file validation.
- Test pagination by requesting unusually large values (e.g.,
limit=100000). - Check for execution timeouts on long-running requests.
- Verify whether expensive endpoints can be abused repeatedly.
- Observe API responses for performance degradation or information disclosure.
Prevention & Best Practices
- Implement strong rate limiting on all sensitive APIs.
- Require authentication wherever possible.
- Set limits for request size, response size, and upload size.
- Configure request timeout values.
- Monitor abnormal API traffic patterns.
- Use API gateways and Web Application Firewalls (WAFs).
- Apply rate limits based on user identity instead of only IP addresses.
- Continuously test APIs for abuse scenarios.
This is Part 4 of my OWASP API Security Top 10 series.
In the next blog, we'll explore OWASP API #5 — Broken Function Level Authorization (BFLA) and learn how attackers abuse privileged API functions to perform unauthorized actions.
Until then, feel free to connect with me on LinkedIn:
www.linkedin.com/in/narmadha-natarajan07
Thank you for reading !