search

stoplightio / spectral-owasp-ruleset

Improve the security of your API by detecting common vulnerabilities as defined by OWASP and enforced with Spectral.
70 stars 11 forks source link

False positive for missing maxLength for format: date #41

Open DavidBiesack opened 1 year ago

DavidBiesack commented 1 year ago

When a property has

type: string
format: date

we get a false positive 

error  owasp:api4:2019-string-limit             Schema of type string must specify maxLength, enum, or const.

Context

The date format must match full-date = date-fullyear "-" date-month "-" date-mday as per RFC 3339 and ISO 8601, such as 2023-04-03 and thus there is an implicit minLength and maxLength of 10 for this format, so there should be no error.

Current Behavior

error diagnostic

error  owasp:api4:2019-string-limit             Schema of type string must specify maxLength, enum, or const.

Expected Behavior

no error

Possible Workaround/Solution

one can explicitly add

minLength: 10
maxLength: 10

but that bloats the OpenAPI definition.

Note that the format may be defined via an allOf construct as well, so it may not be in the same JSON Schema object as the type: string. This may be harder for Spectral to handle:

allOf:
  - $ref: '#/components/schemas/schemaWith_type:_string'
  - $ref: '#/components/schemas/schemaWith_format:_date'

Steps to Reproduce

Environment

paul-kraftlauget commented 10 months ago

I can also note that it is the same with 

type: string
format: date-time

For date-time, it is implicit that maxLength: 30.

I can also note that when generating code using open-api generators, at least with Java, if maxLength is added to a date or a date-time format, the code generator adds a @Size annotation which fails since java validation cannot calculate Size on a date or datetime java objects. So the workaround doesn't work entirely as expected for other parts of the application lifecycle.

This is similar for the UUID format as well: https://github.com/OpenAPITools/openapi-generator/issues/9256

minLength and maxLength should not be required for these known formats.

paul-kraftlauget commented 10 months ago

Additionally, I almost feel warning rules should be shown instead if an API specifies minLength or maxLength on known format types with implicit sizes. However, pattern should perhaps be allowed, if say for example an API would like to always receive date-time values in Zulu time, this can be achieved with a regular expression.

philsturgeon commented 10 months ago

Seeing as format is by default merely an annotation it may not be used at all in the validaiton process. In order to keep things secure, if you're using OpenAPI-based validation, or if you just want to be clear about how that API is going to work, it's better to define the maxLength properties even when there is a format in place.

It might feel weird, but tbh format is weird, and there's no nice answer to that other than a time machine and/or making it never exist.

7.2.1. Format-Annotation Vocabulary

The value of format MUST be collected as an annotation, if the implementation supports annotation collection. This enables application-level validation when schema validation is unavailable or inadequate. Implementations MAY still treat "format" as an assertion in addition to an annotation and attempt to validate the value's conformance to the specified semantics. The implementation MUST provide options to enable and disable such evaluation and MUST be disabled by default. Implementations SHOULD document their level of support for such validation. Specifying the Format-Annotation vocabulary and enabling validation in an implementation should not be viewed as being equivalent to specifying the Format-Assertion vocabulary since implementations are not required to provide full validation support when the Format-Assertion vocabulary is not specified.

https://json-schema.org/draft/2020-12/json-schema-validation#name-format-assertion-vocabulary