Discussion on owasp:api4:2023 (Unrestricted Resource Consumption) rules #551
Description
Should the following linting rules be used for CAMARA APIs:
Descriptions from https://apistylebook.stoplight.io/docs/owasp-top-10-2023\
Errors
owasp:api4:2023-array-limit
Array size should be limited to mitigate resource exhaustion attacks. This can be done using maxItems. You should ensure that the subschema in items is constrained too.
owasp:api4:2023-integer-format
Integers should be limited to mitigate resource exhaustion attacks. Specifying whether int32 or int64 is expected via format.
owasp:api4:2023-integer-limit
Integers should be limited to mitigate resource exhaustion attacks. This can be done using minimum and maximum, which can with e.g.: avoiding negative numbers when positive are expected, or reducing unreasonable iterations like doing something 1000 times when 10 is expected.
owasp:api4:2023-integer-limit-legacy
Integers should be limited to mitigate resource exhaustion attacks. This can be done using minimum and maximum, which can with e.g.: avoiding negative numbers when positive are expected, or reducing unreasonable iterations like doing something 1000 times when 10 is expected.
owasp:api4:2023-rate-limit
Define proper rate limiting to avoid attackers overloading the API. There are many ways to implement rate-limiting, but most of them involve using HTTP headers, and there are two popular ways to do that:
IETF Draft HTTP RateLimit Headers:. https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/
Customer headers like X-Rate-Limit-Limit (Twitter: https://developer.twitter.com/en/docs/twitter-api/rate-limits) or X-RateLimit-Limit (GitHub: https://docs.github.com/en/rest/overview/resources-in-the-rest-api)
owasp:api4:2023-rate-limit-retry-after
Define proper rate limiting to avoid attackers overloading the API. Part of that involves setting a Retry-After header so well meaning consumers are not polling and potentially exacerbating problems.
owasp:api4:2023-string-limit
String size should be limited to mitigate resource exhaustion attacks. This can be done using maxLength, enum or const.
Warnings
owasp:api4:2023-rate-limit-responses-429
OWASP API Security recommends defining schemas for all responses, even errors. A HTTP 429 response signals the API client is making too many requests, and will supply information about when to retry so that the client can back off calmly without everything breaking. Defining this response is important not just for documentation, but to empower contract testing to make sure the proper JSON structure is being returned instead of leaking implementation details in backtraces. It also ensures your API/framework/gateway actually has rate limiting set up.
owasp:api4:2023-string-restricted
To avoid unexpected values being sent or leaked, strings should have a format, RegEx pattern, enum, or const.
Discussion
owasp:api4:2023-integer-limit - for OAS 3.1 (no impact now)
owasp:api4:2023-rate-limit; owasp:api4:2023-rate-limit-retry-after; owasp:api4:2023-rate-limit-responses-429 - implementation/API gateway specific ❌
owasp:api4:2023-array-limit - potential breaking change: using maxItems. You should ensure that the subschema in items is constrained too ✅
owasp:api4:2023-integer-format - potential breaking change: format int32 or int64 must be defined ✅
owasp:api4:2023-integer-limit-legacy - potential breaking change: minimum and maximum must be defined ✅
owasp:api4:2023-string-limit - potential breaking change: maxLength, enum or const - must be used ✅
owasp:api4:2023-string-restricted - only recommendation to use format, RegEx pattern, enum, or const ✅