Does your API skip the sign-in its documentation promises?
This check flags an operation your API description marks as needing sign-in that still returns data to a request without it. Either the description is out of date or the protection is missing.
What does this check look at?
It looks at whether an operation your API description marks as needing sign-in returns data to a request without it. An API that answers some requests with sign-in and the same requests without it is one of the things a scan looks for.
Only a Deep scan runs it, after you prove you own the site.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| High or medium finding | A described-as-protected read returned data with no sign-in. | Enforce sign-in on the route, or correct the description. |
It cannot tell whether the description is out of date or the protection is missing, and either one needs fixing. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.
How serious is a finding?
Fix this first when it is confirmed. Anyone could use a finding of this kind on their own, with no victim and no second step. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label.
What does a confirmed finding have to show?
| Part | For this check |
|---|---|
| Where it starts | Anyone on the internet, with no account, cookie or credential |
| The protection that should stop it | The API description requires sign-in, yet the endpoint answered without it |
| What is reached | The data the endpoint returned |
| What follows | Data the description meant to protect |
Fix it with your AI
Decide which is right, the description or the code, and make the other match.
My OpenAPI description says this operation requires authentication, but it returned data without any: [paste the operation from the report]. Check the route handler and middleware. If the operation should be protected, enforce the declared security scheme on the server. If it is public on purpose, remove the security requirement from the description. Add a test that calls it without credentials and asserts the documented behaviour.How to check
Say Atlas, our example app at atlas.example, documents its invoices route as protected, but a refactor dropped the middleware. A Deep scan flags the mismatch on its first unauthenticated read.
Deep scans come with the Deep plan, and pricing shows what it includes. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
What if the description is just old?
Then fix the description. A wrong description misleads your own team and anyone building on your API.
Did the scan try write operations?
No. Only read-only requests are sent, and returned values are never kept.
Run this check on your site
Only a Deep scan runs this check, once you prove you own the site. Deep walks your whole site, the scripts it loads and your API surface.
Run a Deep scanSources
- How we rate findings Lockpick docs, read on October 7, 2026
- Your admin page is online Lockpick docs, read on October 7, 2026