Should owasp:api4:2019-string-limit run against response objects?

[davidkeaveny]

When a schema component that has a string property is referenced only from GET endpoints, should Spectral flag it as an error?

Example Schema

paths:
  /persons:
     get:
       responses:
         '200':
           content:
             application/json:
               schema:
                 type: array
                 items:
                   $ref: '#/components/schemas/person'
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/createPerson'
components:
  schemas:
    person:
      type: object
      properties:
        name:
          type:string
    createPerson:
      type: object
      required:
        - name
      properties:
        name:
          type:string
          minLength: 1
          maxLength: 1000

When linting this definition with Spectral, it is generating owasp:api4:2019-string-limit errors for the person.name property; if this schema is only being used on a GET endpoint, does specifying a maxLength provide any value? It's fine for writeable endpoints, where I have a specific request object.

Thinking about it, this probably also applies to owasp:api4:2019-array-limit

Current behaviour

Spectral will return the following error:

error  owasp:api4:2019-string-limit                      Schema of type string must specify maxLength, enum, or const.   components.schemas.person.properties.name

Expected behaviour

Spectral will not treat it as an error.

---

• Spectral: 6.8.0
• spectral-owasp-ruleset: 1.4.3
• Node: 18.16.0

[philsturgeon]

It's pretty handy for the client to know how long the data is going to be so they're not getting screwed up trying to bung it all into a field that's too short. Seeing as most folks reuse schema between read/write I dunno how many people are struggling with this.

If anyone has suggestions I'm happy to have a punt at something?