owasp:api7:2019-security-hosts-https-oas3 has incorrect validation per OAS 3.x

[arosenb2]

The ruleset does not align with allowed server hosts that are valid per OAS 3.x.

Documentation

This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the OpenAPI document is being served.

Context

It is firing a false negative with a severity of error.

Current Behavior

A server path starting with a relative path fails linting with a severity of error.

Expected Behavior

No errors or warnings are thrown for the rule when a server path starts with a relative path.

Possible Workaround/Solution

• Change the regular expression used from /^https:/ to /^((?:https:)|(?!\/\/)(?:\/))/
• Error message should be updated to state that relative paths are allowed.

Steps to Reproduce

1. Define an valid OpenApi 3.x document with a relative path for the server
2. Run Spectral CLI
   • spectral lint {doc}
3. See the error thrown

    error  owasp:api7:2019-security-hosts-https-oas3  Server URLs MUST begin https://, and no other protocol is permitted.  servers[0].url

Environment

• Version used: 1.4.0

[philsturgeon]

I hear what you're saying, but if a relative path is being used how can you programatically ensure it's using HTTPS? That's the whole point of this rule afterall.

[arosenb2]

I'd argue that the rule should be interpreted as "if a server path is a fully qualified URI, ensure that it uses HTTPS". If it's a relative path, a warning could be given instead to inform the usage of HTTPS, but forcing usage of a fully qualified URI seems to be an overstep. Another compromise would be explicitly that none of the server paths start with http: instead.

Consider the example of having dynamically named host environments where the API is deployed. A relative server path might be the only option for documentation, but the current implementation of this rule will throw an error (thereby causing the linting process to exit) and force an override to either convert it to a warning or turn it off, potentially causing other API definitions in a monorepo using a shared configuration to miss the validation.

Not everything can be covered in an automated process; API3 and API6 (as examples) are subjective in their methodology and have limited coverage programatically. The ruleset for each ensures that what can be validated is covered but doesn't validate what can't be.

[philsturgeon]

If you're trying to support that use case then warnings don't mean warnings they mean info, "hey did you know" and I've been trying to avoid clutting the messages with loads of warnings for people doing something valid.

Maybe blocking http:// specifically is fine, make a PR and see what people think.

[arosenb2]

Thanks @philsturgeon

[philsturgeon]

I've been given some time to work on this, yaaaay, so I've popped this change into #51

[arosenb2]

Thanks @philsturgeon! Much appreciated!