OpenAPI Security Checklist
Review the security contract before you test the runtime.
Use this checklist during design reviews and pull requests to identify what an OpenAPI 3.0 or 3.1 contract says, what it leaves ambiguous, and what still requires runtime verification.
Start with the controls every operation depends on.
Validate structure
A version string alone does not establish a meaningful contract.
Review effective servers
Confirm intended HTTPS endpoints and inheritance.
Review effective authentication
Check root/operation security, overrides and empty alternatives.
Review declared authorization
Inspect permission alternatives used by sensitive operations.
Identify operations where legitimate access can have high impact.
Object identifiers
Object selectors signal authorization requirements; they do not prove BOLA.
Destructive or privileged methods
Review write/delete, administrative, financial and credential-management operations.
Sensitive schemas
Trace sensitive request and response data.
Examples and defaults
Check for material resembling real secrets rather than placeholders.
Look for inputs and missing evidence that can change the conclusion.
URL-like input
URL, host, callback or redirect inputs can require SSRF review.
Rate-limit evidence
Prefer structured 429 responses, known headers or explicit extensions.
Unresolved surfaces
Unsupported references, cycles, callbacks or invalid structures should reduce coverage.
Result semantics
PASS, FAIL, NOT_EVALUATED, ERROR and partial coverage communicate different facts.
Close the gap between documented intent and effective enforcement.
Verify live authentication, function- and object-level authorization, rate enforcement, SSRF protections, business constraints, data minimization, and network policy.
The document can focus the runtime test plan; it cannot replace it.