Is your sign-in system handing sessions to visitors who never signed in?
This check flags a sign-in library that returns a real user or session to a visitor with no cookie. It usually means a shared cache stored someone’s signed-in answer, and anyone can see or use it.
What does this check look at?
It looks at whether the session address of a known sign-in library returns a real user or session to a visitor who never signed in. Only the field names in the answer are kept, never their values. MDN explains that the no-store directive tells every cache, private or shared, not to store the response.
Only a Deep scan runs it, after you prove you own the site. It applies only when the site uses a recognised sign-in library.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| High finding | A session object came back to a request with no cookie. | Stop caching the session address, purge the cache and sign out affected sessions. |
Only field names are kept, so the report cannot say whose session it was. 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 session route should answer an empty session without cookies |
| What is reached | It returned a session object |
| What follows | Account details or tokens in that session |
Fix it with your AI
Act in this order. Stop new leaks, clear the cached copy, then end sessions that may have been exposed.
URGENT. My sign-in library's session route returns a signed-in user to requests with no cookies, probably from a cache. Set Cache-Control: private, no-store on all auth routes, exclude them from CDN, ISR and edge caching, then tell me how to purge the cached copies at my CDN. Rotate the session secret or revoke active sessions so anything exposed stops working. Add a test that an anonymous session request returns an empty session.How to check
Say Atlas, our example app at atlas.example, enabled full-page caching on its CDN. The first signed-in session answer was cached, and a Deep scan with no cookie got it back.
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
Whose session was it?
The report cannot say. Only field names are kept, so revoke all sessions that could have been cached.
Could the scan use the session?
No. Values are never kept or used. The finding shows that anyone asking the same address could get it.
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
- Cache-Control header MDN Web Docs, read on October 7, 2026
- How we rate findings Lockpick docs, read on October 7, 2026