Spectral "Operation must define a security requirement" — should OpenAPI default to secure?
0 reputation · 11 May 2024, 11:16 UTC
Spectral error: Operation must define a security requirement
While linting an OpenAPI 3.0 document, Spectral's operation-security-defined rule reports Operation must define a security requirement for every operation that lacks an explicit security block when the document has no global security section. In OpenAPI 3.0, such operations inherit no security requirement at all, making them publicly accessible by default.
The specification itself prescribes no default security posture, so the linter is enforcing a convention the spec leaves open. Meanwhile, server generators such as OpenAPI Generator may omit authentication middleware entirely when no security is defined, silently producing open endpoints from a spec that simply omitted the section.
Assume OpenAPI 3.0.x and a recent Spectral version. This can be verified with a minimal YAML lacking global security, linted with that rule enabled, plus a generated Spring Boot stub inspected for missing security annotations.
- Is treating a missing global
securitysection as an error the right default, or should it remain a warning given the spec's silence? - Should generator authors inject authentication middleware by default, or faithfully mirror the spec's openness?
- Is there any movement toward a spec-level default (e.g., a
defaultSecurityfield) that tooling should align with?