Notifications
Clear all
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.
NHIMG editorial — based on content published by Salt: Unrestricted resource consumption and API security risk
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
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 APIs with expensive parameters create more risk than simple request floods?
A: Expensive parameters let an attacker trigger disproportionate server work with a single valid-looking call.
Q: How do security teams know if API abuse controls are working?
A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load.
Practitioner guidance
- Define cost thresholds for expensive endpoints Identify the API operations that can trigger large database reads, recursive processing, or high-volume responses, then set explicit ceilings for page size, payload size, and execution cost.
- Apply multi-dimensional rate limits Rate limit by identity, token, session, IP, and endpoint so that one abused control cannot be bypassed by switching context.
- Baseline normal parameter behaviour Build behavioural models for key API parameters, then alert when values move outside expected ranges.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- Endpoint-specific examples of oversized `max_return` and `page_size` abuse across real API flows.
- How Salt describes baseline modelling for normal parameter values and anomaly detection.
- The practical differences between static proxy limits and application-aware enforcement.
- The source article's walkthrough of how resource exhaustion can enable brute force and data leakage.
👉 Read Salt's analysis of unrestricted resource consumption in API security →
API resource limits and rate limiting: are your controls keeping up?
Explore further
02/08/2026 12:37 pm
API exhaustion is now an access-control problem, not just a performance problem. When attackers can turn one endpoint into a CPU, memory, or data amplification layer, the organisation is no longer only defending uptime. It is defending the integrity of authentication, session, and data access flows that sit behind the API. That is why this issue belongs in identity-adjacent governance discussions as much as in application security reviews. Practitioners should treat resource abuse as a control boundary failure, not a mere tuning issue.
A question worth separating out:
Q: Who should own API abuse risk when authentication and data access are involved?
A: Ownership should be shared across application security, IAM, and the teams that run the API. IAM owns the trust model for identities and tokens, application teams own endpoint behaviour, and security engineering owns detection and policy. If any one group treats the issue as someone else’s problem, brute force and enumeration gaps will persist.
👉 Read our full editorial: Unrestricted resource consumption is exposing API security gaps
