-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy path.spectral.yaml
65 lines (60 loc) · 3.19 KB
/
.spectral.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
extends:
- spectral:oas
# note this only covers the 2019 top ten https://github.com/stoplightio/spectral-owasp-ruleset/issues/47
- https://unpkg.com/@stoplight/[email protected]/dist/ruleset.mjs
# 2.0.0 breaks the build throwing the following error:
# "scope.sandbox.value.match is not a function"
#- https://unpkg.com/@stoplight/[email protected]/dist/ruleset.mjs
rules:
# override a couple of rules that erroneously apply to HEAD requests
"owasp:api3:2019-define-error-responses-500":
message: "Operation is missing {{property}}."
description: 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.
given: $.paths.*[get,put,post,patch,delete].responses
then:
- field: "500"
function: truthy
- field: "500.content"
function: truthy
"owasp:api3:2019-define-error-responses-500-head":
message: "Operation is missing {{property}}."
description: 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.
given: $.paths.*[head].responses
then:
- field: "500"
function: truthy
"owasp:api3:2019-define-error-responses-401":
message: "Operation is missing {{property}}."
description: "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."
given: $.paths.*[get,put,post,patch,delete].responses
then:
- field: "401"
function: truthy
- field: "401.content"
function: truthy
# we do not require content for rate limiting
"owasp:api4:2019-rate-limit-responses-429":
given: $.paths..responses
then:
- field: "429"
function: truthy
"should-have-422":
message: "Operation is missing {{property}}."
description: ""
given: $.paths.*[put,post,patch].responses
then:
- field: "422"
function: truthy
- field: "422.content.application/problem+json"
function: truthy
overrides:
- files:
# the created response's headers are used but
# since the bodies are not empty, the entire
# response is not used anywhere. However, for consistency
# and to keep the individual responses DRY, we want
# to keep the 201 in the root openapi file, so we
# disable the unused component rule for this response
- "docs/openapi-1.0.yaml#/components/responses/201"
rules:
oas3-unused-component: "off"