OpenAPI Security Checklist
Review the security contract before you test the runtime.
This checklist is for design reviews and pull requests where an OpenAPI 3.0 or 3.1 document is available. It helps identify what the contract says, what it leaves ambiguous, and what still requires runtime verification.
1–4 / Identity and transport
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 operation/path/root inheritance.
- Review effective authentication. Check root and operation-level
security, overrides, and whether an empty requirement object makes authentication optional. - Review declared authorization. Inspect permission alternatives used by sensitive operations and flag expansive grants for human review.
5–8 / Resources and data
Identify operations where legitimate access can have high impact.
- Object identifiers. Parameters such as
{user_id}can signal object-level authorization requirements. They do not prove BOLA. - Destructive or privileged methods. Review write/delete operations, administrative paths, financial actions, and credential-management functions.
- Sensitive schemas. Trace request and response schemas containing credentials, identity, financial, contact, session, or other sensitive data.
- Examples and defaults. Check examples, defaults, headers, and parameter values for material that resembles real secrets rather than placeholders.
9–12 / Abuse and coverage
Look for inputs and missing evidence that can change the conclusion.
- User-controlled URL-like input. URL, host, callback, or redirect fields can require SSRF review.
- Rate-limit evidence. Prefer structured 429 responses, known rate-limit headers, or explicit extensions. Text saying “no rate limit” is not mitigation.
- Unresolved surfaces. Unsupported external references, cycles, callbacks/webhooks, or invalid structures should reduce coverage rather than become silent PASS results.
- Result semantics. Distinguish PASS, FAIL, NOT_EVALUATED, ERROR, and partial coverage. “Nothing found” is not “fully evaluated.”
Runtime follow-up
Close the gap between documented intent and effective enforcement.
After contract review, verify live authentication, function- and object-level authorization, rate enforcement, SSRF protections, business constraints, data minimization, and network policy. The document can focus the test plan; it cannot replace it.