CORS (Cross-Origin Resource Sharing) is a browser mechanism that uses HTTP headers to let a server declare which other origins may read its responses. It relaxes the default same-origin policy in a controlled way, so APIs can be shared without exposing them to every website.
By default, browsers block a page on one origin from reading responses from another. CORS headers let a server opt specific origins back in. Configured well it enables legitimate cross-site APIs; configured carelessly (e.g. a wildcard with credentials) it can leak data.
Check your website
See how your site handles cors: sharing resources across origins safely — free, no account needed.
For business owners
CORS is what lets your front-end talk to your API — or lets partners integrate with your service — without opening a security hole. Misconfigured CORS is a common source of both frustrating "blocked by CORS" bugs and real data-leak vulnerabilities, so getting it right keeps integrations working and customer data safe.
How it works (technical)
The browser enforces the same-origin policy; CORS is how a server grants exceptions. For a cross-origin request the browser may send a preflight OPTIONS request, and the server responds with headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers. The critical rule: you may not combine Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — reflect a specific, validated origin instead. CORS is enforced by the browser, not the server, so it protects users, not the API itself; APIs still need their own authentication and authorisation.
Real-world example
A team set Access-Control-Allow-Origin: * together with credentialed requests to "make CORS errors go away". This let any website make authenticated requests on behalf of logged-in users. Switching to an allowlist that echoes only trusted origins closed the hole while keeping the legitimate front-end working.
Why it matters
CORS controls cross-origin data exposure in the browser. Scanners check for dangerous configurations such as a wildcard origin combined with credentials.
How to fix it
Decide exactly which origins legitimately need access to each endpoint.
Return
Access-Control-Allow-Originwith a specific, validated origin — not a blanket*for credentialed requests.Restrict
Access-Control-Allow-MethodsandAllow-Headersto what is actually needed.Never combine
Allow-Origin: *withAllow-Credentials: true.Remember CORS is not authentication — keep proper auth on the API itself.
Best practices
Maintain a strict allowlist of trusted origins rather than reflecting any origin.
Scope allowed methods and headers as tightly as possible.
Treat CORS as a browser convenience, not a substitute for server-side authorisation.
Common mistakes
Using
Access-Control-Allow-Origin: *with credentials, exposing user data.Reflecting the request Origin header without validating it against an allowlist.
Assuming CORS protects the API — it only constrains browsers.
Frequently asked questions
Does CORS protect my API from attackers?
No. CORS is enforced by browsers to protect users. Scripts, servers and tools can call your API regardless, so it always needs its own authentication and authorisation.
Why do I get a CORS error only in the browser?
Because CORS is a browser policy. The same request from curl or a server has no CORS restriction. Fix it by returning the correct Access-Control headers for the calling origin.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free