owasp-protection-global-unsafe-strict
POST, PUT, PATCH, and DELETE operations should require authentication. Define a non-empty security requirement on the operation, or let it inherit the root requirement.
An operation’s security value replaces the root value. security: [] disables inherited authentication, and an empty requirement ({}) permits anonymous access. Adding {} beside an authenticated alternative still permits anonymous access.
Changed behavior: this rule now reports an error, rather than info. Existing anonymous write operations can now fail lint runs.
Bad example
openapi: "3.1.0"
info:
title: Chicken Nuggets API
version: "1.0"
security:
- NuggetsAuth: []
paths:
/chickenNuggets:
post:
security:
- NuggetsAuth: []
- {}
responses:
'201':
description: Chicken nugget created
components:
securitySchemes:
NuggetsAuth:
type: http
scheme: bearer
Good Example
openapi: "3.1.0"
info:
title: Chicken Nuggets API
version: "1.0"
security:
- NuggetsAuth: []
paths:
/chickenNuggets:
post:
responses:
'201':
description: Chicken nugget created
components:
securitySchemes:
NuggetsAuth:
type: http
scheme: bearer
How do I fix this violation?
Define at least one authenticated requirement and remove anonymous alternatives. In the good example, the operation inherits the root requirement. An empty scope list such as NuggetsAuth: [] is valid for bearer authentication; it is different from an empty requirement ({}).
For an intentionally public write operation, document the reason and use the existing x-lint-ignore directive on that operation. For a ruleset-wide exception, use a custom ruleset severity override.
Current limitation: an inherited root security: [] is not reported. Use an authenticated root requirement; a clean result does not prove every write operation requires authentication.
This rule checks the declared requirement. It does not prove that the API enforces authentication or authorization.
The original rule came from api-oas-checker.
