Skip to content
rest/security/exposure-contradiction

Exposure conflicts with authentication

Declared exposure agrees with effective OpenAPI security.

error

Examples

FlaggedFails
{
"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
}
}
PassesClean
{
"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
}
}
FlaggedFails
{
"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
}
}
PassesClean
{
"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.

  1. Review root security inheritance and operation-level security alternatives.
  2. 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.