Few things frustrate developers like a CORS error — a request that works in one tool but the browser blocks in your app. The error messages are cryptic, and the instinct is to disable security entirely. Understanding what CORS protects, and how it actually works, turns that frustration into a quick fix.
The same-origin policy
By default, browsers enforce the same-origin policy: JavaScript on one origin (scheme + domain + port) cannot read responses from a different origin. This protects users — without it, a malicious site could read your bank’s API using your logged-in session. CORS is the controlled way for a server to say "these other origins are allowed."
How CORS grants access
CORS works entirely through response headers from the server being called. When the server includes Access-Control-Allow-Origin with your origin (or *), the browser permits your JavaScript to read the response. Without that header, the request may still reach the server, but the browser refuses to hand the response to your code.
Preflight requests
For anything beyond simple requests — custom headers, methods like PUT or DELETE, certain content types — the browser first sends an OPTIONS "preflight" request asking whether the real request is allowed. The server must answer with the appropriate Access-Control-Allow-Methods and Allow-Headers. A failed preflight is the cause of many confusing CORS errors.
Fixing CORS the right way
The fix is almost always on the server: configure it to send the correct Access-Control headers for the origins you trust. Resist the urge to slap Allow-Origin: * on everything, especially for authenticated endpoints — that re-opens the very hole the policy closes. CORS is not the problem; it is the mechanism for solving it safely.