CORS Explained Without Confusion

An origin is the exact combination of scheme, host, and port — https://dashboard.example.com and https://api.example.com are different origins even though they share a parent domain; so are http://example.com and https://example.com, and example.com:3000 and example.com:8080. The browser's same-origin policy (SOP) says JavaScript running on one origin cannot read the response of a request to a different origin, by default.

The reason is the browser automatically attaches cookies to every request to a site, including ones triggered by a different page's JavaScript. Without SOP, a malicious page could fetch('https://bank.example.com/balance') in the background, ride the victim's existing session cookie, and read the balance in the response — an attack the ambient nature of cookies makes possible unless something blocks the read. SOP blocks it by default; CORS is the mechanism a server uses to explicitly open a hole in that default for specific origins.

A simple request — method GET, HEAD, or POST; only safelisted headers (Accept, Accept-Language, Content-Language); and a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain — goes straight over the wire with no preliminary check. The server receives it, runs its handler, and returns a response exactly as it would for a same-origin call. Only after the response arrives does the browser check whether Access-Control-Allow-Origin permits the calling page's origin to read it. If not, the response exists, the server-side work happened, and the page's JavaScript simply never sees the result.

This is the gap that catches teams off guard: a cross-origin POST with a form-urlencoded body that increments a counter, sends an email, or writes a row is a simple request. It reaches the server and executes whether or not CORS ultimately lets the page read the response. CORS was never a request-blocking mechanism for this category — it is a response-reading mechanism, and the side effect already happened by the time it runs.

Any request outside the simple-request rules — a PUT, PATCH, or DELETE, a custom header like Authorization or X-Request-Id, or (very commonly) a JSON body sent with Content-Type: application/json — triggers a preflight. Before sending the real request, the browser sends an OPTIONS request carrying Access-Control-Request-Method and Access-Control-Request-Headers, asking the server whether the real request would be allowed.

The server answers with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers on the OPTIONS response — no body, no side effect, nothing executed yet. Only if that preflight response permits the method and headers does the browser send the actual request. This is the opposite ordering from a simple request: here, a rejected preflight means the real request is never sent at all. Access-Control-Max-Age lets the browser cache a successful preflight result so repeated calls skip the extra round trip until it expires.

By default, fetch does not send cookies cross-origin at all. Setting credentials: "include" tells the browser to attach cookies to a cross-origin request — and the server must respond with Access-Control-Allow-Credentials: true for the browser to let the page read the result. Critically, the CORS specification forbids combining a wildcard Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. A credentialed cross-origin endpoint must echo back one specific, validated origin — never a wildcard.

That means a server accepting credentialed requests from more than one origin needs to read the request's Origin header, check it against an allowlist, and reflect back exactly that value (never an unvalidated echo of whatever Origin header arrived, which would defeat the purpose entirely). Reading a custom response header client-side needs one more opt-in: by default JavaScript can only read a small safelisted set of response headers (Content-Type, Content-Length, and a few others) — anything else needs Access-Control-Expose-Headers naming it explicitly.

Trigger. A new dashboard at https://dashboard.example.com calls POST https://api.example.com/widgets/42/like with a form-urlencoded body — a simple request — before anyone configured CORS headers on the API. Symptom. The browser console shows a CORS error and the JavaScript catch block reports failure to the user, so the team assumes the click did nothing. Support tickets report like counts silently climbing anyway.

Root mechanism. The request was simple, so it reached the server, ran the handler, and incremented the counter — the browser only blocked the response from being read by the calling page's JavaScript, well after the increment already happened. Recovery: add Access-Control-Allow-Origin: https://dashboard.example.com to the API's response and confirm the same button click now both increments the counter and updates the UI. Verification: query the widget's like count directly before and after a blocked-looking click to confirm the increment already occurred even during the failure window. Prevention: treat any cross-origin-callable endpoint with a side effect as one that can be called without its response ever being read — make it idempotent (an operation key, a check-before-write) so a retry triggered by an apparent CORS failure can't double the effect.