Topic starter
02/08/2026 9:44 am
TL;DR: Unrestricted resource consumption has replaced lack of resources and rate limiting in the OWASP API Security Top 10, because oversized requests and missing limits can trigger denial of service, brute force, enumeration, and data exfiltration, according to Salt. Static WAF and gateway controls rarely understand normal application behaviour well enough to stop parameter abuse without breaking legitimate traffic.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API4:2023 Unrestricted Resource Consumption”.
Key questions
Q: What breaks when API resource limits are missing?
A: Without resource limits, a small number of calls can trigger large backend workloads, causing slow responses, timeouts, service instability, and unexpected cloud spend.
Q: Why do unrestricted API requests increase brute force and exfiltration risk?
A: When an API allows high-frequency retries, attackers get more chances to guess credentials, test tokens, or walk through record sets quickly.
Q: What are the signs that an API is being probed for abuse?
A: Common signs include repeated tweaks to user IDs or object IDs, a growing number of errors from the same entity, and requests that test privilege escalation or access boundaries.
Practitioner guidance
- Define endpoint-specific resource ceilings Set hard limits for page size, payload size, recursion depth, and other request-cost drivers on each API route rather than using one blanket control.
- Throttle authentication and data-heavy routes Apply adaptive rate limiting to login, token, search, and record-retrieval endpoints so repeated attempts cannot be used for brute force or enumeration.
- Baseline normal parameter behaviour Profile expected values for fields such as max_return, page_size, and similar inputs, then alert when requests deviate materially from those ranges.
Bottom line: Unrestricted resource consumption is a control failure because APIs can be pushed into denial of service, brute force, enumeration, and data leakage by abusing request size or request frequency.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:37 pm
Unrestricted resource consumption is really a trust-boundary failure. The API assumes a caller will stay within expected resource bounds, but that assumption collapses when the endpoint exposes expensive operations to untrusted inputs. In identity-heavy systems, this turns login, token, and record-retrieval paths into abuse channels. Practitioners should treat resource ceilings as part of the access model, not as optional performance tuning.
A few things that frame the scale:
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: How should teams govern rate limiting alongside API security controls?
A: Treat rate limiting as one layer in a broader API governance model that also covers parameter validation, endpoint cost, and authentication abuse. Gateway controls are useful, but they are not enough if they do not understand the application’s normal behaviour. Teams should align the limits with service ownership, not with a generic network policy.
👉 Read our full editorial: Unrestricted resource consumption is exposing API security gaps