Does an API route on your site answer without signing in?
This check sends one read-only request with no cookie, token or key to API routes your site uses, and flags any that return data. Some routes are public by design, and private ones must refuse.
What does this check look at?
It looks at whether an API address the site uses returns data to one read-only request with no cookie, token or key. Being reachable isn't a problem by itself. The trouble starts when something reachable also answers without asking who you are. Only the status, the field names and a record count are kept, never a value.
A Deep scan never signs in, never changes anything on your site, never tries to break in and never reads your code.
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 route returned data with no sign-in, and its field names look sensitive. | Require sign-in on the server, and check the caller owns the data. |
| Low or info finding | A route returned data that may be public by design. | Confirm it is meant to be public. |
Some endpoints are public on purpose, and field names alone do not prove the data is sensitive. 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 endpoint answered with no sign-in |
| What is reached | The data the endpoint returned |
| What follows | What the returned fields hold; sensitive-looking fields raise it |
Fix it with your AI
Protect the route on the server, then prove it with a test that a request without a session is refused.
This API route answered a request with no session: [paste the route and method from the report]. If it should be private, add an authentication check in the route handler or middleware that returns 401 with no session, and check the signed-in user is allowed to see the specific records returned. If it is public on purpose, make sure it returns only fields meant for anyone. Add a test that calls the route without a session and expects 401 or 403.How to check
Say Atlas, our example app at atlas.example, has an orders route its dashboard calls. A Deep scan sends one request without a cookie, gets orders back and flags it, keeping only the field names.
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
How does the scan know which routes to try?
From the routes your own site code and public API description already name, plus a short list of common ones. Lockpick does not publish that list.
A route returns public data on purpose. Will it keep flagging?
It is rated by what the field names suggest. Public data with no sensitive-looking fields stays low or informational.
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
- What a Deep scan does Lockpick docs, read on October 7, 2026
- Your admin page is online Lockpick docs, read on October 7, 2026