rest/security/exposure-contradiction Exposure conflicts with authentication
Declared exposure agrees with effective OpenAPI security.
error
Examples
{ "documents": { "openapi.json": { "info": { "title": "Fixture", "version": "1" }, "openapi": "3.1.2", "paths": { "/widgets": { "get": { "responses": { "200": { "description": "ok" } } } } }, "security": [ { "oauth": [] } ] } }, "entrypoint": "openapi.json", "semantics": { "artifacts": [], "operations": [ { "exposure": "public", "operation_ref": "#/paths/~1widgets/get" } ], "schema_version": 1 }}{ "documents": { "openapi.json": { "info": { "title": "Fixture", "version": "1" }, "openapi": "3.1.2", "paths": { "/widgets": { "get": { "responses": { "200": { "description": "ok" } } } } }, "security": [ {} ] } }, "entrypoint": "openapi.json", "semantics": { "artifacts": [], "operations": [ { "exposure": "public", "operation_ref": "#/paths/~1widgets/get" } ], "schema_version": 1 }}{ "documents": { "openapi.json": { "info": { "title": "Fixture", "version": "1" }, "openapi": "3.1.2", "paths": { "/widgets": { "get": { "responses": { "200": { "description": "ok" } } } } }, "security": [ {} ] } }, "entrypoint": "openapi.json", "semantics": { "artifacts": [], "operations": [ { "exposure": "authenticated", "operation_ref": "#/paths/~1widgets/get" } ], "schema_version": 1 }}{ "documents": { "openapi.json": { "info": { "title": "Fixture", "version": "1" }, "openapi": "3.1.2", "paths": { "/widgets": { "get": { "responses": { "200": { "description": "ok" } } } } }, "security": [ { "oauth": [] } ] } }, "entrypoint": "openapi.json", "semantics": { "artifacts": [], "operations": [ { "exposure": "authenticated", "operation_ref": "#/paths/~1widgets/get" } ], "schema_version": 1 }}Why it matters
Generated consumers can enforce the opposite authentication requirement.
How detection works
An operation marked public has no anonymous security alternative, or one marked authenticated allows anonymous access.
What is inspected
- an exact operation_ref sidecar declaration and computed effective security alternatives
Limits
- inferring exposure
- proving runtime authorization
- evaluating scopes
- Only operations with an explicit sidecar exposure declaration are checked.
- Root inheritance, operation overrides, empty arrays, and empty requirement objects are modeled.
- Invalid security structures make analysis inconclusive instead of producing a finding.
How to fix it
Align declared exposure and effective security.
- Review root security inheritance and operation-level security alternatives.
- Change either the explicit exposure declaration or the OpenAPI security requirement.
Verify
- Run repo-lint rest check again against the same tracked contract and semantics.