Access to fetch has been blocked by CORS policy: Response to preflight request doesn't pass access control check

The exact error

Access to fetch at 'https://api.example.com/users' from origin
'https://app.example.com' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check:
It does not have HTTP ok status.

The message can also end with variants like "No 'Access-Control-Allow-Origin' header is present on the requested resource" or "The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'" — all describing the same underlying mechanism failing for different specific reasons, covered as separate causes below.

How to read this error in 30 seconds

1. Open DevTools → Network tab, reload, find the OPTIONS request to the same URL (it sits directly before your real GET/POST/PUT request).
2. Check its status code — anything other than a 2xx response fails the preflight outright, regardless of what headers it returns.
3. Check its response headers for Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers — the Console's error text usually names exactly which one is missing or wrong.
4. Confirm whether your request sends credentials (cookies, Authorization header with credentials: 'include') — this changes what's a valid Allow-Origin value, covered in Cause 3 below.

The preflight flow, visually

The key thing this diagram makes visible: steps 1–3 are a completely separate round trip that happens automatically, entirely inside the browser and network stack, before your application code's request is ever attempted. Your fetch() call and your server's real route handler both live at step 4 — if step 3 fails, execution never reaches either one, which is why debugging your actual endpoint's logic is a waste of time until the preflight itself passes.

Cause 1 — there's no route/handler for OPTIONS at all

// ❌ only a GET handler exists — an OPTIONS request to this same
//    path has nothing to match, and most frameworks 404 it by default:
app.get("/users", (req, res) => res.json(getUsers()));

// ✅ Express's built-in cors() middleware auto-handles OPTIONS for
//    every route it's applied to — this is the standard, low-effort fix:
const cors = require("cors");
app.use(cors({ origin: "https://app.example.com" }));
app.get("/users", (req, res) => res.json(getUsers()));

Many web frameworks route incoming requests strictly by method + path, meaning a route registered only for GET genuinely has no matching handler for an OPTIONS request to the identical path — the framework falls through to a default 404 or 405 response, which fails the preflight's "must return a 2xx status" requirement before any CORS headers are even considered. Reaching for a maintained CORS middleware (cors for Express, django-cors-headers for Django, flask-cors for Flask) rather than hand-rolling OPTIONS handling is the standard fix, since these libraries register the necessary catch-all OPTIONS behavior for you across every route automatically.

Cause 2 — a hand-rolled OPTIONS handler is missing a required header

// ❌ handles OPTIONS but forgets Allow-Methods and Allow-Headers —
//    the preflight then fails for any non-GET method or custom header:
app.options("/users", (req, res) => {
  res.set("Access-Control-Allow-Origin", "https://app.example.com");
  res.sendStatus(204);
});

// ✅ a preflight response needs all three, matching what the actual
//    request will use:
app.options("/users", (req, res) => {
  res.set("Access-Control-Allow-Origin", "https://app.example.com");
  res.set("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
  res.set("Access-Control-Allow-Headers", "Content-Type, Authorization");
  res.sendStatus(204);
});

A hand-written OPTIONS handler is a common source of partial CORS support: it's easy to add Access-Control-Allow-Origin (the header most people know about) while forgetting that Access-Control-Allow-Methods and Access-Control-Allow-Headers are independently checked against what the actual request intends to send. If your real request will use PUT or send an Authorization header, the preflight response must explicitly list both — the browser cross-references the preflight's allow-list against the upcoming real request and fails validation if anything the real request needs isn't pre-authorized here.

Cause 3 — wildcard origin used with credentialed requests

// client sends credentials:
fetch("https://api.example.com/users", { credentials: "include" });

// ❌ wildcard is explicitly disallowed once credentials are involved —
//    the spec forbids this combination for security reasons:
res.set("Access-Control-Allow-Origin", "*");

// ✅ echo back the exact requesting origin instead, plus explicitly
//    allow credentials:
res.set("Access-Control-Allow-Origin", req.headers.origin);
res.set("Access-Control-Allow-Credentials", "true");

The CORS specification deliberately forbids Access-Control-Allow-Origin: * whenever the request carries credentials (cookies, HTTP auth, or a client-set Authorization header combined with credentials: 'include'/withCredentials: true) — a wildcard combined with credentials would let literally any origin on the internet make authenticated requests on a logged-in user's behalf, which is precisely the cross-site request forgery scenario CORS exists to prevent. The correct pattern is to reflect the specific requesting origin (read from the incoming Origin request header, validated against an allow-list server-side) rather than a wildcard, alongside an explicit Access-Control-Allow-Credentials: true.

Cause 4 — a reverse proxy or CDN strips CORS headers before they reach the browser

# confirm what actually reaches the browser vs. what your app sent —
# curl the same OPTIONS request directly against the proxy/CDN edge:
curl -X OPTIONS -i https://api.example.com/users \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: PUT"
# compare against curling the origin server directly, bypassing the
# proxy, if you have a way to do so (internal IP, different port)

Your application code can return perfectly correct CORS headers and still fail this check if an nginx configuration, a load balancer, or a CDN edge rule in front of it strips or rewrites headers on the response path — a common outcome of an overly aggressive proxy_hide_header directive, a caching layer that caches an earlier response missing the headers, or a WAF rule that isn't aware CORS headers need to pass through untouched. Comparing what your application actually sent against what the browser actually received (via a direct curl to the origin vs. through the full proxy chain) isolates whether the bug is in your CORS logic or in infrastructure sitting in front of it.

Common variants

Debugging checklist

• ✓ Find the OPTIONS request in DevTools Network tab and check its status code first
• ✓ Confirm Allow-Origin, Allow-Methods, and Allow-Headers are all present and match what your real request needs
• ✓ If using credentials, confirm the origin is echoed literally, not wildcarded
• ✓ curl the OPTIONS request directly to rule out a proxy/CDN stripping headers
• ✓ Prefer a maintained CORS middleware over hand-rolled OPTIONS handling