Array schema in a response has no maximum number of items defined

🛠️ Tools
1

We have some APIs that can return a variable number of items in a list, typically controlled with some pagination inputs. For example:

    "200":
      description: Request was successful
      content:
        application/json:
          schema:
            type: object
            properties:
              pagination:
                $ref: "#/components/schemas/pagination"
              data:
                type: array
                items:
                  type: object
                  allOf:
                    - $ref: "#/components/schemas/org"
                    - $ref: "#/components/schemas/org_expandable"

The Security Audit report is complaining that there isn’t a maximum number of items defined. The main drawback to specifying a maximum number of items is that, ultimately, the max number is indirectly controlled by the input of number of items per page. So I could, for example, specify that the max number is 10 (the default page size) but then, if the page size is set to 100, I could get 100 results, thus violating the API contract.

Is there a way of turning off the requirement for maxItems to be defined (in a request as well as in a response)?

2

Hi Philip :wave:

Great question!

The rule can’t be disabled from the IDE extension at the moment, but I’ll make a note of it for our team to consider adding that capability in the future.

That particular security rule is intended to raise awareness of the potential risk from excessive data exposure (on the response) or DOS attack (on the request).

For instance data scraping via API’s is becoming a popular attack vector, so the idea is by setting an upper limit on the volume of data the API can return, you can limit the damage done in the event of a successful attack (often used in conjunction with rate limiting).

But what limits to set, if any, depends of course on your particular use case and risk appetite.

You could remove the issue from the report by setting some arbitrary large number for maxItems, but I wouldn’t recommend it. It might be better to simply leave the warning in place as a reminder, in case your risk on that API changes in the future and you need to reconsider the need for limits.

If you have a different opinion, do let me know…

3

Thanks for your reply, @Anthony

I’m happy to define limits where I can in the API contract but APIs with pagination responses seem almost impossible to apply a sensible value for maxItems. As you say, I could apply a large number just to remove the issue but it isn’t sensible.

Eventually, I want to incorporate schema auditing into a CI pipeline so that changes are checked to ensure that the contract is still passing the rules. That means we need to have a way of getting to the point where we have no errors. At the moment, it looks like omitting maxItems is classed as an error (at least in VS Code with the red cross in a circle).

4

@Philip_Colmer
If later you’re running the Audit CICD extension (rather than the IDE extension) you have more options to customize the pass/fail criteria, and possibly add exceptions for Audit rules.

You can read more details here. That example is for Azure pipelines, but there’s similar information under the other supported CI solutions (Github, Jenkins, Bamboo, etc.).