New guidelines for OWASP API Security Top 10 too restricted (or lack guidelines)

[tlohmar]

Problem description

The PR #582 introduced more restrictive requirements into Commonalities 0.7-rc1 as required by OWASP.

For example, PR #582 introduces the general requirement "If the data type is string, maxLength property or enum construct MUST be used to constrain values.", while the OWASP issue is an "Unrestricted Resource Consumption", i.e. only on input strings, either in a queryline or path parameter or in a POST, PATCH or PUT request body. Meaning, OWASP does not require string constrains for string, which are generated by the API provider function.

Expected behavior

Review the OWASP guideline and check, whether the restrictions should only be applied to input parameters (i.e. strings or arrays or integers).
Discuss, whether restrictions should also be applied to output parameters, i.e. parameter values, which are generated by the API provider function.

Give some guidance, how to determine the restrictions. The principle can be for example, that the API specification is not restricting the deployments (e.g. recommend usage of the maximal possible value) and recommend implementations for further restricting it (with clear error code support).

Alternative solution

Additional context

[Kevsy]

I feel that the length of response strings could be an indirect security issue, e.g. if the size of response impacted performance and availability at the API server. But the backend response size can be limited by the operator before it gets written to the API response. So from that perspective I agree that the 'hard' constraint should apply at inout only, as OWASP says.

However, there could be benefit to the API Consumer understanding what is the maximum Content-Length they can expect to process (as this could affect response and processing delay), and whether to expect a chunked response. That's not a security issue but would be helpful for APIs where this could apply.

[tlohmar]

@Kevsy thanks for your elaboration.

I start realizing, that we have a mix of issue here.
1: The OWASP issue is only about "resource consumption", i.e. query line input, input headers or HTTP Bodies of POST, PUT or PATCH. However, there is also an issue on the output side, like you pointed out.
2: Limited Integers, Arrays or Strings and provide the appropriate behavior (i.e. throwing an error without crashing or worse) is typically an implementation issue. Of course, with increasing amount of auto-generated code (e.g. based on a yaml file), it gets more likely that handling such is missed. Thus, better to start pushing API specification developers to think about reasonable limits.
3: CAMARA aims to define standard-like API specifications. The API specifications are essential for compliance testing, ensuring interoperability between vendors (API client vendor and API server vendor). A standard should give, where needed, enough room for implementation flexibility, preferably without impacting interoperability.
4: Commonalities define guidelines, which are supposed to be followed by all CAMARA API developing communities. These guidelines should trigger that API developing communities to select reasonable limits. However, is that always a single limit or is it ok to allow for a limit range (min & max), allowing for some implementation flexibility?

The commonalities guideline is a document, which targets API specification developers as audience and there should be clear guidance, how to select these limits. The API developing communities should create APIs and documentation, which target the API consumers (and API provider developers). For many cases, it is easy, e.g. a UUID is limited to 36 characters. My thinking is, that the guideline should include some recommendations how to select these limits.
For example,

• Select the max limit (integer, Array or String) based on the known format.
• Determine reasonable large limit, so that the specification does not limit implementation and that the specification limits the waste.
• Maybe allow for implementation or deployment specific limits by requiring a minimal limit. Here, the API specification must be clear, e.g. by adding statements like "Implementations may decide to select a lower limit, which is required to be larger than X", or so.

[Kevsy]

Thanks @tlohmar - I think the key point is

A standard should give, where needed, enough room for implementation flexibility, preferably without impacting interoperability.

I believe 'without Impacting interoperability' implies 'by reducing the complexity for the API Consumer'. So if the API Consumer has to account for implementation differences, then ideally:
1- allow those differences to be machine-readable
2- identify the exception clearly and indicate what the API Consumer needs to do to resubmit the request.

Done properly, that could avoid the unwelcome scenario in mobile development, where a switch block includes a separate case for each mobile operator.