Zuplo · API Governance Rules
Zuplo — rate my openapi rules
Spectral linting rules defining API design standards and conventions for Zuplo.
21 Rules
error 1
warn 10
info 10
Published by Zuplo
Served by the provider at https://github.com/zuplo/rate-my-openapi/blob/24819fbe7576e2811b3be2750312e2cea64bcf14/rulesets/.spectral.yaml; the copy below was fetched from there.
Rule Categories
apimatic
owasp:api1:2019
owasp:api2:2019
owasp:api3:2019
owasp:api4:2019
owasp:api7:2019
redocly
speakeasy
Rules
warn
apimatic-security-defined
Apimatic: It is recommended to define at least one authentication scheme globally using the securitySchemes property in the components section and use it globally to authenticate all the endpoints or use it for specific endpoints.
$
info
apimatic-operationId-max-length
Apimatic: Longer content can lead to issues in the code generation process. It's best to keep the length to a maximum of 50 characters, wherever possible.
$.paths..operationId
info
apimatic-parameter-name-max-length
Apimatic: Longer content can lead to issues in the code generation process. It's best to keep the length to a maximum of 50 characters, wherever possible.
$.paths..parameters[*].name
info
apimatic-header-name-max-length
Apimatic: Longer content can lead to issues in the code generation process. It's best to keep the length to a maximum of 50 characters, wherever possible.
$.paths..responses..headers[*]~
info
apimatic-component-name-max-length
Apimatic: Longer content can lead to issues in the code generation process. It's best to keep the length to a maximum of 50 characters, wherever possible.
$.components.[schemas,requestBodies,responses,parameters,examples,headers,securitySchemes][*]~
info
apimatic-no-inline-response-schema
Apimatic: In general, inline schemas are not encouraged in code generators and API portal generators since their names are inferred from the parent node in which they are defined inline.
$.paths..responses..content..schema
info
apimatic-no-inline-parameter-schema
Apimatic: In general, inline schemas are not encouraged in code generators and API portal generators since their names are inferred from the parent node in which they are defined inline.
$.paths..parameters[*].schema
info
apimatic-no-inline-request-body-schema
Apimatic: In general, inline schemas are not encouraged in code generators and API portal generators since their names are inferred from the parent node in which they are defined inline.
$.paths..requestBody.content..schema
warn
owasp:api1:2019-no-numeric-ids
OWASP API1:2019 - Use random IDs that cannot be guessed. UUIDs are preferred.
$.paths..parameters[*][?(@property === "name" && (@ === "id" || @.match(/(_id|Id|-id)$/)))]^.schema
warn
owasp:api2:2019-no-http-basic
Basic authentication credentials transported over network are more susceptible to interception than other forms of authentication, and as they are not encrypted it means passwords and tokens are more easily leaked.
$.components.securitySchemes[*]
warn
owasp:api3:2019-define-error-responses-401
OWASP API Security recommends defining schemas for all responses, even errors. The 401 describes what happens when a request is unauthorized, so its important to define this not just for documentation, but to empower contract testing to make sure the proper JSON structure is being returned instead of leaking implementation details in backtraces.
$.paths..responses
warn
owasp:api3:2019-define-error-responses-500
OWASP API Security recommends defining schemas for all responses, even errors. The 500 describes what happens when a request fails with an internal server error, so its important to define this not just for documentation, but to empower contract testing to make sure the proper JSON structure is being returned instead of leaking implementation details in backtraces.
$.paths..responses
info
owasp:api4:2019-rate-limit
Define proper rate limiting to avoid attackers overloading the API. There are many ways to implement rate-limiting, but most of them involve using HTTP headers, and there are two popular ways to do that: IETF Draft HTTP RateLimit Headers:. https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/ Customer headers like X-Rate-Limit-Limit (Twitter: https://developer.twitter.com/en/docs/twitter-api/rate-limits) or X-RateLimit-Limit (GitHub: https://docs.github.com/en/rest/overview/resources-in-the-rest-api)
$.paths[*]..responses[?(@property.match(/^(2|4)/))]
info
owasp:api4:2019-rate-limit-retry-after
Define proper rate limiting to avoid attackers overloading the API. Part of that involves setting a Retry-After header so well meaning consumers are not polling and potentially exacerbating problems.
$..responses[429].headers
info
owasp:api4:2019-rate-limit-responses-429
OWASP API Security recommends defining schemas for all responses, even errors. A HTTP 429 response signals the API client is making too many requests, and will supply information about when to retry so that the client can back off calmly without everything breaking. Defining this response is important not just for documentation, but to empower contract testing to make sure the proper JSON structure is being returned instead of leaking implementation details in backtraces. It also ensures your API/framework/gateway actually has rate limiting set up.
$.paths..responses
warn
owasp:api7:2019-security-hosts-https-oas3
All server interactions MUST use the https protocol, meaning server URLs should begin `https://`. Learn more about the importance of TLS (over SSL) here: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
$.servers..url
warn
redocly-operation-summary
Operation summaries are used to generate API docs. Redocly uses the summary as the header for the operation, as well as the sidebar navigation text. See https://redocly.com/docs/cli/rules/operation-summary/
$.paths.*[?( @property === 'get' || @property === 'put' || @property === 'post' || @property === 'delete' || @property === 'options' || @property === 'head' || @property === 'patch' || @property === 'trace' )]
error
redocly-components-invalid-map-name
All components MUST use keys that match the regular expression: ^[a-zA-Z0-9.-_]+$ See https://redocly.com/docs/cli/rules/spec-components-invalid-map-name/
$.components.schemas[*]~$.components.parameters[*]~$.components.securitySchemes[*]~$.components.requestBodies[*]~$.components.responses[*]~$.components.headers[*]~$.components.examples[*]~$.components.links[*]~$.components.callbacks[*]~
warn
redocly-no-server-variables-empty-enum
If you use server variables, there are generally two kinds: tenant-driven and environment-driven. In the case of environment-driven variables, you may want to predefine all of the possible values. See https://redocly.com/docs/cli/rules/no-server-variables-empty-enum/
$.servers[*].variables[*]
warn
redocly-no-undefined-server-variable
Document all declared server variables to make it easier to consume the API. See https://redocly.com/docs/cli/rules/no-undefined-server-variable/
$.servers[?(@.url.match(/({)/))]
warn
speakeasy-parameter-name-nonempty
All parameters must have a non-empty name. See https://www.speakeasyapi.dev/docs/openapi/validation
$.paths..parameters..name
Spectral Ruleset
Work with this as data
Every ruleset here is available over the APIs.io API and to AI agents over MCP.