no-additionalProperties rule overrides constrained-additionalProperties rule

[ydidio]

Context

Everything is in OpenAPI 3.0.X
The use of additionalProperties has become basically invalid because we want to enforce all owasp security rules, even though technically it should be accepted as an object when defined together with maxProperties.

Current Behavior

The constrained-additionalProperties rule ensures if I use additionalProperties as an object, I must define maxProperties too.

The no-additionalProperties rule ensures that if I define additionalProperties, it must be set to false.

The problem is the no-additionalProperties rule does not differentiate when additionalProperties is used as a boolean or as an object, which means if I define additionalProperties as an object and define maxProperties, the no-additionalProperties rule will still fail it with an error, completely invalidating the constrained-additionalProperties rule.

Expected Behavior

The no-additionalProperties rule should look specifically at additionalProperties as a boolean, or more so when additionalProperties: true is set, and should not override the constrained-additionalProperties rule.

Possible Workaround/Solution

This is the current given for the no-additionalProperties rule:
given: "$..[?(@ && @.type==\"object\" && @.additionalProperties)]".

I suggest replacing it with
given: "$..[?(@ && @.type==\"object\" && @.additionalProperties && @.additionalProperties==true)]" or something else that allows the rule to differentiate between additionalProperties as an object or as a boolean.

Steps to Reproduce

Gonna include three schemas:

1. first one should not fail either rule because it has maxProperties and additionalProperties as an object:

requestSurveyInput:
          additionalProperties:
            type: string
            maxLength: 500
          type: object
          nullable: true
          description: Survey input given to this request
          maxProperties: 20
          example:
            question: answer

It currently fails the no-additionalProperties rule but it shouldn't.

2. second schema should fail the no-additionalProperties rule because it defines it as true rather than as an object.

AccessRequestApproverAction:
      type: object
      properties:
        approver:
          $ref: '#/components/schemas/AccessRequestApprover'
        result:
          $ref: '#/components/schemas/AccessRequestResult'
      required:
        - approver
        - result
      additionalProperties: true   # ❌ should trigger your error rule

3. third schema should not fail either because it defines additionalProperties: false. It already doesn't, just putting it here because this functionality must remain.

rawMetricHistory:
      title: rawMetricHistory
      x-stoplight:
        id: fvptu31c9qpfn
      type: object
      additionalProperties: false
      properties:
        metricType:
          type: string
          x-stoplight:
            id: ln2jsgmvj5fjk
          pattern: '^[A-Z_]+$'
          minLength: 3
          maxLength: 60
        days:
          type: integer
          x-stoplight:
            id: 2tw31pm0iph7w
          format: int64
          maximum: 365
          minimum: 1
        data:
          type: array
          nullable: false
          x-stoplight:
            id: 6ubhvtamu1ug0
          maxItems: 365
          minItems: 0
          items:
            $ref: '#/components/schemas/metricDateValue'

Environment

Same thing when run locally or using a github action or swaggerhub or stoplight.

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your environment/workspace/project: