An API should apply a modest default page size and a hard maximum even when the client asks for more, and the SDK should paginate for the caller instead of requesting everything at once. Unbounded list requests are an easy way to exhaust memory, bandwidth and budget.
The risk, in OWASP terms
OWASP lists unrestricted resource consumption as API4 in its 2023 API Security Top 10. It notes that APIs often do not limit client interactions, and that crafted requests, including ones with parameters that control how many resources are returned, can exhaust capacity. It names limits that may be missing: execution timeouts, maximum memory, maximum upload file size, number of operations in a single request, and the number of records per page to return in a single request response. Its mitigation guidance asks you to define and enforce a maximum size of data on incoming parameters and payloads, such as maximum length for strings, maximum number of elements in arrays and maximum upload size, and to limit how often a client can call the API.
Limits to set, in one table
| Limit | Where it lives | Notes |
|---|---|---|
| Default page size | Server | Applied when the client sends none |
| Maximum page size | Server | Clamp requests above it, or reject with a clear error |
| Maximum request body size | Gateway and server | Include per field string and array limits |
| Rate limit per client | Gateway | Return Retry-After on throttle |
| Query timeout | Server | Stops expensive filters hanging |
| Total result window | Server | Cap how deep a client can page |
Steps to implement
- Choose a default that serves most callers in one request, and a maximum that you can serve at peak load. Test both with realistic data volumes.
- Clamp or reject. Silent clamping is friendly, but document it, and return the effective page size in the response so clients are not confused.
- Prefer cursor based pagination for large or changing collections. Offset pagination gets slower the deeper it goes, which attackers can exploit.
- Limit expensive filters and sorts to indexed fields, and cap the number of filters in one request.
- Pair limits with rate limits per credential, and send a Retry-After header when you throttle, as the HTTP specification describes.
- In the SDK, provide an iterator that follows cursors and applies backoff, and make the default page size match the server default.
- Set a spending limit or alert on any third party service your endpoints call, as OWASP suggests, so a single abusive client cannot run up the bill.
- Monitor the distribution of requested page sizes. A sudden jump in requests at the maximum is a signal worth investigating.
What the SDK should not do
It should not offer an "all" option that loops forever and loads everything into memory. If callers need a full export, give them a documented export endpoint with its own limits, authentication scope and audit logging. See data minimization in API design for ways to shrink what each response carries.
Try it yourself
Open the demo to see how an API security scan reports findings, and look for any that relate to missing limits.
Click through it at your own pace, or open it full screen.
Quick check
Should a request above the maximum be clamped or rejected?
Either works if documented. Clamping is friendlier, rejection is more explicit. Return the effective page size so clients know what happened.
Is a rate limit enough without page limits?
No. A single large request can be costly on its own, so size limits and rate limits work together.
Safeguard's API security scanning, policies and gates, and free scan at gold.safeguard.sh/scan help you check endpoints against rules like these before release.
Sources
- OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption
- RFC 9110: HTTP Semantics, section 10.2.3
Last reviewed: 19 October 2026.
