CORS & preflight: the browser's rule, the server's opt-in

An origin is scheme + host + port. Compared with https://app.example.com:

The same-origin policy is a browser rule: a script running on one origin may send many kinds of requests to another origin, but it may not read the response unless that other origin says it may. CORS (Cross-Origin Resource Sharing, defined in the Fetch standard) is how the other origin says so — with response headers.

Here is that rule in a real browser. A page on http://localhost:4124 fetches http://localhost:4123/no-cors, an endpoint that sends no CORS headers:

server log:      GET /no-cors  origin=http://localhost:4124       <- the request arrived and ran
page's script:   TypeError: Failed to fetch                       <- the response was withheld

$ curl http://localhost:4123/no-cors
{"secret":"visible to curl, hidden from other origins' scripts"}

Three facts in that one experiment:

1. The request reached the server and the handler ran. CORS did not stop it.
2. The browser blocked the page from reading the response, because nothing in it said http://localhost:4124 was allowed. To the script it's an opaque network error; MDN notes that CORS failure details "are not available to JavaScript" — the reason appears only in the browser console.
3. curl got the data. CORS is enforced by browsers, for scripts running in web pages. curl, a Node server, a mobile app's HTTP client — none of them implement it, so none of them ever see a CORS error.

The fix for the page is on the server: send Access-Control-Allow-Origin: http://localhost:4124 (or * for a public, non-credentialed resource) and the browser hands the response to the script. Nothing you write in the page's fetch call can grant itself that permission.

An API at https://api.example.com serves a web app at https://app.example.com (and an admin app on another origin). The app sends cookies, so requests are credentialed. Here's the whole CORS layer in plain Node:

const ALLOWED_ORIGINS = new Set(["https://app.example.com", "https://admin.example.com"]);

/** Returns true when it answered the request itself (a preflight). */
function handleCors(req: IncomingMessage, res: ServerResponse): boolean {
  const origin = req.headers.origin;
  const allowedOrigin = origin && ALLOWED_ORIGINS.has(origin) ? origin : null; // exact match only

  res.setHeader("Vary", "Origin");                   // the answer depends on Origin: tell caches
  if (allowedOrigin) {
    res.setHeader("Access-Control-Allow-Origin", allowedOrigin);   // the one origin, never "*"
    res.setHeader("Access-Control-Allow-Credentials", "true");
  }

  const isPreflight = req.method === "OPTIONS" && req.headers["access-control-request-method"] !== undefined;
  if (!isPreflight) return false;                    // a real request: let the route run

  if (!allowedOrigin) {
    res.writeHead(403).end();                        // no grant headers: the browser stops here
    return true;
  }
  res.writeHead(204, {
    "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE",
    "Access-Control-Allow-Headers": "authorization, content-type",
    "Access-Control-Max-Age": "600",
  }).end();
  return true;
}

Probed with curl (Node 24): a preflight from https://app.example.com gets 204 with all the grant headers; one from https://app.example.com.evil.test gets 403 with only Vary: Origin; a request with no Origin at all gets the data and no CORS headers.

The credential rules

From the Fetch standard's table of legal and illegal combinations:

And with credentials, * in Access-Control-Allow-Methods, -Allow-Headers or -Expose-Headers is not a wildcard either — it means a method or header literally named *. Tested in Chrome: a credentialed request to an endpoint answering Allow-Headers: * failed its preflight; the same request without credentials passed.

Why each line is there

• Exact match from a list. Access-Control-Allow-Origin holds exactly one origin or *; you can't list several. To serve several, compare the request's Origin against your list and echo the match.
• Vary: Origin on every response, allowed or not. The response now differs by Origin, and the Fetch standard spells out the failure without it: a cache stores a response that has no Access-Control-Allow-Origin (say, from a navigation) and later serves it to a CORS request, which then fails.
• No grant on a refused preflight. A 403 without CORS headers is how the standard suggests saying no explicitly.

CORS protects the user's browser from other sites reading responses as that user. It does not protect your server from requests. Three consequences that catch people out:

1. Simple requests run before anyone checks

In the browser test from the first example, the request to an endpoint with no CORS headers reached the server and its handler ran; the browser only withheld the answer from the page. A simple POST behaves the same way — a text/plain or form body needs no preflight — so a cross-site form or fetch can trigger a state-changing POST on your API whatever your CORS headers say. Stopping that is CSRF protection (Web Security track), not CORS.

2. Origin is just a header

$ curl -i -H 'Origin: https://app.example.com' https://api.example.com/cart

Anything that isn't a browser can send any Origin it likes. A browser sets it honestly for the page's own origin — which is the only reason it's useful — so "only answer requests from our origin" is never authentication. Every request still needs real credentials checked on the server.

3. A sloppy allow-list hands your users' data to any site

With credentials allowed, every origin on the list can read responses made with the user's cookies. These all look like allow-lists and aren't:

The safe shape is boring: a Set of exact, full origins (scheme, host and port, no trailing slash), checked with Set.has — exact string equality. If you truly need every subdomain, parse the origin with new URL(origin) and compare url.protocol and url.hostname (=== "example.com" or .endsWith(".example.com") — with the leading dot) rather than matching the raw string.

When it's not your API

You can't fix CORS from the browser side. If a third-party API doesn't allow your origin, call it from your own server — a route handler or backend-for-frontend endpoint on your origin — where CORS doesn't apply, and keep any API key there instead of in the page.