CORS is a browser-enforced security mechanism that controls which cross-origin HTTP requests are permitted from JavaScript. By default the same-origin policy blocks scripts on evil.com from reading responses on yourbank.com. A server opts trusted origins in by returning Access-Control-Allow-Origin and related headers on its responses.
Why it matters
A misconfigured CORS policy is a frequent source of real security incidents. Pairing Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true exposes authenticated APIs to any origin, which can leak session data or enable account takeover. Reflecting the request Origin header without an allowlist is just as dangerous. On the other side, overly strict CORS quietly breaks frontends, embedded widgets, and partner integrations — and the failures only show up in the browser console, never on the server. CORS interacts with csrf defences, so misconfiguring it can also undermine cookie-based protections.
How to configure
- Maintain an explicit allowlist of trusted origins; never reflect
Originblindly. - Use
*only for genuinely public, unauthenticated endpoints — and never alongside credentials. - Understand simple vs preflighted requests:
PUT,DELETE, custom headers, or non-standardContent-Typetrigger anOPTIONSpreflight. - Cache preflights with
Access-Control-Max-Ageto reduce latency. - Vary the response on the
Originheader so caches do not serve the wrong allowlist entry. - Combine with csp, hsts, and a proper referrer-policy for defence in depth, and enforce https everywhere.