Validate the format of examples

[tatomyr]

Is your feature request related to a problem? Please describe.

Consider this definition sample:

openapi: 3.0.0

components:
  parameters:
    foo:
      in: query
      name: foo
      schema:
        type: string
        format: ipv4
      example: wrong

Although the example is wrong, linter doesn't recognise this.

Describe the solution you'd like
It would be great if no-invalid-parameter-examples rule could take format into account as well.

Describe alternatives you've considered
None

Additional context

See more details here.

[tatomyr]

See also: #1470

[LasneF]

notice that the partial support of format is a pain , because when using in conjonction with oneOf the current implementation make the validation failing in all case when adding a sample as it patches always both item of the oneOf

    maturity:
      description: Maturity date or tenor 
      type: string
      oneOf:
        - format: date
        - pattern: ^\d+[YyMmWwDd]|\d+[YyMmWwDd]\d+[YyMmWwDd]

[tatomyr]

A similar issue.

[adamaltman]

Same issue exists with schema examples.

Maybe we should support format validation one-by-one? Starting with the most obvious formats like date, date-time, pattern?

[tatomyr]

Maybe we should support format validation one-by-one? Starting with the most obvious formats like date, date-time, pattern?

Redocly CLI relies on AJV for validating examples, and AJV is supposed to be used together with the ajv-formats plugin to validate formats. It should be comparatively easy to start adding some formats.

However, there is a potential security issue of ReDoS attack:

It is recommended NOT to use "format" keyword implementations with untrusted data, as they may use potentially unsafe regular expressions

So the main issue here, I believe, is to assess the potential security impact.

[LasneF]

redocli CLI looks not an appropriate target for a redos Attack, given redocly is used as a linter tooling (meaning validation a file that you are in control) . The worst case i can establish would be some one introducing a poisonned spec with nasty sample in a CICD that could lock the production chain . Usually this kind of attack is used in a runtime mode like an API gateway or a backend code and so not a redocly use case

One remediation can be to applies validation on sample only for the format part and not for the pattern part
This would be already a great step , especially considering the format date for instance , here as the pattern is controled internaly by redocly it should not be something really subject to attacks

then given the the attack vector being to intput a bad pattern , and then a bad sample that make infinite loop, an other remediation ( to check if it is possible) is to apply a time out for exemple validation that would significantly reduce the impact of the attack.

[tatomyr]

@LasneF I think you're right in your assumptions. It's mostly a matter of priorities 😅.

[lornajane]

Since the formats are more like advice than strict types, let's add the ability to not check formats as a configuration setting on the rule.