To test CORS, send requests with several Origin headers, including one you do not own, and read the Access-Control-Allow-Origin response. Approved origins should be returned exactly, unknown ones should get no allow header, and a wildcard must never be combined with credentials. Check preflight responses too.
What CORS controls
CORS lets a server say which other origins a browser may read responses from. It is enforced by the browser, not the server, and it does not stop non-browser clients. MDN documents the rules: a request with credentials must not receive a wildcard origin, and the browser will block it.
What to look for
| Response behavior | Risk |
|---|---|
| Echoes any Origin back | Any site can read responses |
| Allows the string null as an origin | Sandboxed pages can read data |
| Wildcard on an endpoint using cookies | Browser blocks it, but shows a misconfiguration |
| Allow-Credentials true with a broad pattern match | Attacker domains that match the pattern |
| No Vary: Origin when the value changes | Caches may serve the wrong value |
Steps
- List endpoints that return user data or accept cookies.
- Send a request with your approved origin and note the allow header.
- Send the same request with a random origin, with an origin that ends with your domain as a suffix, and with the value null.
- Send a preflight OPTIONS request with a method and headers, and read the allowed methods and headers lists. MDN notes that credentialed requests need explicit values rather than wildcards.
- Check the Max-Age value so preflight caching is reasonable.
- Confirm Vary: Origin is present when you return a specific origin. MDN says caches need it so one origin's answer is not served to another.
Fix direction
Keep an explicit allowlist of origins and compare exact strings, not patterns or suffixes. Return the matched origin, not a wildcard, for credentialed endpoints. Allow only the methods and headers the client needs. Public read-only APIs without cookies may reasonably use a wildcard.
A common confusion
A CORS error in the console is not a vulnerability by itself. It is the browser enforcing your policy. The vulnerability is a policy that is too permissive.
Try it yourself
Look for the CORS and header findings in the scan output.
Click through it at your own pace, or open it full screen.
Quick check
Does CORS protect my API from attackers?
No. It restricts browsers. Direct clients ignore it, so you still need authentication and authorization.
Is a wildcard origin always wrong?
No. It can be fine for public data with no credentials. It is a problem when responses depend on cookies or tokens.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and policies and gates that can block a pull request, so the libraries behind your app are checked alongside the app itself. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
