Cross-Origin Resource Sharing (CORS) tells browsers which other websites may read responses from your API. A misconfigured CORS policy can let any website read your users' private data through their own browser.

How it happens

The most common mistakes are reflecting whatever Origin the request sends, trusting the null origin, or matching origins with a loose pattern, all while allowing credentials. A malicious site can then call your API from a victim's browser and read the response.

Why it matters

• Theft of personal and account data from authenticated API responses.
• Exposure of API keys or tokens returned by endpoints.
• Undermining of same-origin protections your front end relies on.

How to prevent it

• Allow-list exact trusted origins; never reflect arbitrary origins.
• Never trust the null origin.
• Only send Access-Control-Allow-Credentials: true when truly needed.
• Review CORS whenever you add a new front-end domain.

How Vooki Pro helps

• Tests for permissive CORS, origin reflection and trusted null origins.
• Checks the wider set of security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy and more).
• Consolidates header findings per origin so you fix each one once.
• Exports results as HTML, PDF, Word or JSON to share with your team.

Frequently asked questions

Why is reflecting the Origin header dangerous?

If the server echoes any Origin and allows credentials, any website can read authenticated responses from your API through a victim's browser.

Is Access-Control-Allow-Origin: * insecure?

The wildcard cannot be combined with credentials, so it is safe for truly public data but should never be used for authenticated endpoints.

Related: Open redirect vulnerabilities