Default behavior for additionalProperties has changed in OAS3.1

[philsturgeon]

the functionality in the repo was contradicting itself, saying it had to be false but also another rule allowed it to be an object. OAS3.0 is additionalPorperties: false by default, and OAS3.1 is additionalProperties: true by default. It seems like we should address that, by making OAS3.1 users use additionalProperties, and saying it either needs to be false or an object with maxProperties set?

Motivation and Context

#InsertIssueNumberHere

Description

How Has This Been Tested?

Screenshot(s)/recordings(s)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• This PR's code follows as closely as possible the coding style/guidelines of this project.
• I have added error reporting and followed the error reporting guidelines.
• I have added event tracking and followed the event tracking guidelines.
• I have updated any relevant documentation accordingly to reflect this PR's changes.
• I have added automated tests (unit/integration/e2e/other) to cover my changes.
• All new and existing tests pass locally (excluding flaky CI tests).

[philsturgeon]

@DavidBiesack I'd be interested in your thoughts on this, as the default behavior for additional properties has changed in OAS 3.1 to make it more permissive. The rules you wrote for #50 are the same as the old rules: they'll look for this keyword and if used will restrict it to false, or an object with maxProperties, but perhaps 3.1 needs a new approach?

[DavidBiesack]

@philsturgeon
Re "the default behavior for additionalProperties has changed in OAS 3.1 to make it more permissive."
Can you provide a citation for that? https://spec.openapis.org/oas/v3.1.0 does not specify any behavior or changes (only uses additionalProperties in some examples) and the JSON Schema 2020/12 core changelog does not help either (only mentions "Comment on ambiguity around annotations and "additionalProperties")

[philsturgeon]

JSON Schema has always allowed additional properties by default, that hasn't changed.

What did change in OpenAPI v3.1 was schema becoming a proper JSON Schema Vocabulary instead of something vaguely based off the concept of JSON Schema. One of these changes included a change that means extra properties are welcome without needing to necessarily start with x-.

In v3.0.3 the Schema Object section of the spec says:

Additional properties defined by the JSON Schema specification that are not mentioned here are strictly unsupported.

In v3.1.1 the Schema Object section of the spec says:

In addition to the JSON Schema properties comprising the OAS dialect, the Schema Object supports keywords from any other vocabularies, or entirely arbitrary properties.

Another change is from this in 3.0.x

This object MAY be extended with Specification Extensions.

To this in 3.1.x:

This object MAY be extended with Specification Extensions, though as noted, additional properties MAY omit the x- prefix within this object.

tl;dr: Y'all can do what you want now.

[DavidBiesack]

@philsturgeon That 3.0.3 vs. 3.1.0 language is not talking about the JSON schema additionalProperties keyword (i.e. whether a JSON value can have properties not listed in the schema properties) but whether a schema object can have additional fields not defined by OAS or JSON Schema.
For OWASP, it is too strict to warn if a schema does not have additionalProperties (as i may use unevaluatedProperties which is more flexible when used with a schema that is composed from other schemas. I think the rule should advise one or the other, but there are situations when they should not be used, i.e. for a schema that is referenced/used to compose other schemas.

[DavidBiesack]

or additionalProperties: { '$ref: .... }

[DavidBiesack]

double } } should be just } at the end of the sentence

[philsturgeon]

@DavidBiesack

That 3.0.3 vs. 3.1.0 language is not talking about the JSON schema additionalProperties keyword (i.e. whether a JSON value can have properties not listed in the schema properties) but whether a schema object can have additional fields not defined by OAS or JSON Schema.

Well exactly. OWASP does not have opinions about how OpenAPI or JSON Schema is written. OWASP is concerned about whether additional keywords can be sent than you're expecting.

In OpenAPI v3.0 the assumption was default off, and you would have to say "yeah thats fine" with additionalProperties: true, so we'd look for that and say "dont do that".

In OpenAPI v3.1 the assumption is that you can, so it feels like we should tell everyone to turn that off. Right?

It feels like its a bigger change than just changing additionalProperties to unevaluatedProperties, it's a change in the default behavior which means a change in how we approach the rules.