List in output has no maximum number of items defined

Possible exploit scenario

Without a maxItems or equivalent constraint, the API contract does not clearly specify the expected upper bound of returned collections. If no maximum constraint is defined, the API may return:

• Unexpectedly large result sets
• Excessive related data
• Internal data — potentially sensitive — that is not intended for bulk exposure
• Amplified payloads caused by backend logic flaws

This can lead to:

• Acciental bulk data exposure
• Increased attack surface for enumeration
• Increased response sizes
• Performance degradation for API consumers, with downstream systems potentially overwhelmed
• Amplification of response size in federated graphs
• Difficulty detecting anomalous responses

If a backend filtering mechanism is bypassed or misconfigured, an attacker may trigger a query that returns a much larger dataset than intended. For example, a field expected to return recent transactions might accidentally return an entire historical dataset if backend filtering fails. Without a defined upper bound, this deviation might not be detectable at the contract level.

Attackers strive to make your APIs behave in an unexpected way to learn more about your system or to cause a data breach. Good data definition quality in the schemas used in API responses allows reliably validating that the contents of outgoing API responses are as expected.

While filtering API responses does not block a specific kind of attack, it is there as a damage control mechanism in the unfortunate event that a successful attack has been conducted: it allows blocking the response and prevent attackers from retrieving data they should not access.

In the vast majority of cases (with the notable exception of Denial of Service (DoS and DDoS) attacks) attacks are conducted because attackers want to access data or resources they should not have access to. Often, this means that the structure or the size of the API response changes as a result of a successful attack, compared to a normal API response.

Validating that API responses are as expected can be achieved through proper schema validation of the API responses. The accuracy of this depends on the quality of the response schemas: the better defined your schemas are, the easier it is to detect when something is not right.