# Does your site let other websites read responses with your visitors’ cookies?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The CORS check sends one request with an unrelated origin and flags a response that trusts it while allowing credentials. Here is why that matters.

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.

:::fix-prompt any
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](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/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.

## Sources

- [Access-Control-Allow-Credentials header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Access-Control-Allow-Credentials), MDN Web Docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07