Cross-Origin Resource Sharing (CORS) tells a browser which origins are allowed to read responses from your API. By default, browsers block most cross-origin reads. CORS lets you relax that on purpose. When the policy is too open, it can expose data you meant to keep private.
Why the policy matters
Developers often loosen CORS to get a front end talking to an API during development, then forget to tighten it. Two common mistakes stand out:
- Reflecting whatever origin sends the request back in
Access-Control-Allow-Origin, which effectively trusts every site. - Combining a wildcard or reflected origin with
Access-Control-Allow-Credentials: true, which can let another site read authenticated responses.
CORS is not a CSRF defense
A permissive CORS policy does not protect you from Cross-Site Request Forgery, and a strict one is not a substitute for anti-CSRF tokens. Treat them as separate controls. Anti-CSRF tokens remain your first line of defense against forged requests, and CORS controls who can read responses.
Configure it safely
Prefer an explicit allowlist of the exact origins that need access, and avoid pairing wildcards with credentials. A safer response looks like this:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: OriginSet the origin per request from a known allowlist rather than echoing it blindly, and include Vary: Origin so caches behave. A misconfigured CORS policy is a common finding in a web application security test.
Have a system you want tested?
Tell us what you are working with and we will follow up with next steps.