Does your site let other websites read responses with your visitors’ cookies?
The CORS check sends one request that claims to come from an unrelated website, with no cookies, and flags a response that trusts that website while allowing browser credentials.
What does this check look at?
It looks at whether a response trusts an unrelated website as an origin while allowing browser credentials. MDN explains that credentials include cookies and authentication headers, and that this header tells browsers whether the server allows them in cross-origin requests.
Pulse and Deep scans both run it.
What does a result mean?
| What the report shows | What it means | What to do |
|---|---|---|
| Medium finding | An unrelated origin was echoed back with credentials allowed. | Allow only the origins you trust, from a fixed list. |
No visitor cookie is sent, so it does not show private data can be read from another site. It also does not show what a signed-in visitor would see from that response. 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 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 | Any website a signed-in visitor opens |
| The protection that should stop it | Access-Control-Allow-Origin reflected an unrelated origin with credentials allowed |
| What is reached | The browser lets that website read the response with the visitor's cookies |
| What follows | Whatever this route returns to a signed-in visitor |
Which standards does it relate to?
| Standard | Reference |
|---|---|
| OWASP Top Ten | A01:2025 Broken Access Control |
| CWE | CWE-942 |
| ASVS | v5.0.0-3.4.2 |
Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.
Fix it with your AI
The usual cause is code that copies the request Origin into the response. Replace it with an allowlist.
My server reflects any Origin in Access-Control-Allow-Origin while sending Access-Control-Allow-Credentials: true. Find the CORS configuration or middleware that does this. Replace it with a fixed allowlist of the exact origins that need credentialed access, return no CORS headers for any other origin, and add Vary: Origin. Add a test that a request from an unlisted origin does not get Access-Control-Allow-Origin back.How to check
Say Atlas, our example app at atlas.example, uses a CORS library set to reflect every origin. The check flags the reflected test origin, and the allowlist fixes it.
Run a Pulse scan from your Lockpick account to see it for your site. Pulse or Deep explains what each scan reads, and the full list of checks shows the rest.
Questions people ask
Is Access-Control-Allow-Origin set to a wildcard the same problem?
No. Browsers refuse to send credentials to a wildcard response. Reflecting any origin with credentials allowed is the dangerous combination.
Did the scan read private data?
No. It sent no cookies. A real attack needs a signed-in visitor to open the attacker page, so the finding needs a victim to matter.
See what your site shows from outside
A quick check reads your homepage the way a visitor would and gives you a score. No account needed.
Check your siteSources
- Access-Control-Allow-Credentials header MDN Web Docs, read on October 7, 2026
- How we rate findings Lockpick docs, read on October 7, 2026