In OpenAPI, security set to an empty array on an operation removes the top level security requirement, so that route is documented as needing no authentication. An empty requirement object inside the array makes authentication optional. Both are legitimate for login or health routes and risky when added by accident.
What the specification says
The OpenAPI Specification explains that the root security field declares which mechanisms can be used across the API, and only one requirement in the list needs to be satisfied. An operation's security replaces the root declaration. In the spec's words, "To remove a top-level security declaration, an empty array can be used." To make security optional, "an empty security requirement () can be included in the array."
| Form | Meaning |
|---|---|
| No security on operation | Inherits the root requirement |
| security: [] on operation | No authentication required |
| security with a scheme listed | That scheme replaces the root |
| security containing an empty object plus a scheme | Authentication is optional |
Why scanners and reviewers care
A scanner uses the description to decide what credential to send. If an operation says no security, the scan may send none and report the route as open, or skip authentication checks entirely. A reviewer reading the description should treat every empty array as a question: is this route meant to be public?
Generators can produce this form without you typing it. Some framework configurations mark routes as public when an annotation or decorator is missing, so the description may show an empty list for a route that is actually protected by other code, or the reverse. The description describes your intent as the generator understood it. It does not enforce anything. Enforcement lives in the framework's security layer.
Steps to review your description
- Export the current OpenAPI file.
- Search for security with an empty array or an empty object, for example with grep on the file.
- List each operation found, with its path and method.
- Mark each as intentionally public or not.
- For the unintended ones, fix the underlying framework rule and regenerate. Do not just edit the file by hand, or it will drift. See OpenAPI spec drift.
- Add a CI check that fails when a new empty security entry appears without review.
Typical legitimate uses
Login and token endpoints, a health probe, a public status page, and a webhook that authenticates by signature instead of by bearer token. Even these deserve a note in the description field saying why they are open.
What the description cannot tell you
A route with a declared scheme can still be broken. If the code never checks the token, the description is wrong in the other direction. That is why scans send real requests instead of trusting the file. The declaring schemes post covers the positive side.
Try it yourself
Click through it at your own pace, or open it full screen. Check how findings reference specific operations.
Safeguard's dependency and SBOM scanning is a quick companion step, and a free scan is available.
Quick check
Does security: [] make a route insecure?
It documents the route as open. Whether that is a problem depends on whether the route should be public.
Does the description enforce security?
No. The framework's own checks do. The file only describes.
Sources
Last reviewed: 19 October 2026.
