Could a shared cache hand one visitor another visitor’s session?
This check reads the session address of a recognised sign-in library, such as Auth.js or Better Auth, as a visitor with no cookie. An empty answer is normal, and the check looks at whether a shared cache could store it.
What does this check look at?
It looks at whether the session address of a known sign-in library answers visitors with no cookie, and whether a shared cache could keep its answer. 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 |
|---|---|---|
| Info finding | The address answered an empty session and cannot be shared by a cache. | Nothing beyond keeping no-store on it. |
| Medium finding | The answer could be stored by a shared cache. | Send no-store and keep the auth routes out of your CDN cache. |
An empty answer is how these libraries work, so a reachable address does not prove a flaw on its own. 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 soon. A finding of this kind needs a victim or a second step before it causes harm, so it ranks below anything someone could use directly. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. 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 | A shared cache between visitors and the site |
| The protection that should stop it | Cache headers let the session route be stored |
| What is reached | A cached session answer |
| What follows | One visitor's session details served to another |
Fix it with your AI
One header and one CDN rule cover it.
Make sure my sign-in library's session and auth routes can never be cached by a CDN or proxy. Set Cache-Control: private, no-store on every auth route response, exclude the auth route prefix from CDN, ISR and edge caching, and add a test that an anonymous request to the session route gets an empty session with no-store. Show me the config changes.How to check
Say Atlas, our example app at atlas.example, put its whole site behind an aggressive CDN cache rule. The session address answers with a cacheable header, and the check flags it before anyone signs in behind that cache.
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
Is a public session address a problem?
No. Sign-in libraries answer it with an empty session by design. The risk is a cache storing a signed-in answer and serving it to someone else.
Did Lockpick sign in to test this?
No. It only asks as a visitor with no cookie and reads the cache headers.
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