Response to preflight request doesn't pass access control check

The exact console message

Access to fetch at 'https://api.example.com/data' from origin 'https://your-site.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Chrome prints this generic wrapper whenever an OPTIONS preflight request fails its validation checks. The text after the final colon provides the real diagnosis for why the browser rejected the response.

What the browser is telling you

Your browser determined that the planned HTTP request required a preflight check, typically because it uses non-safelisted methods or headers such as Content-Type: application/json. Before dispatching the actual request, the browser issued an automatic OPTIONS request to verify that the server permits the cross-origin call.

The server's response to that OPTIONS probe failed one of the browser's CORS rules. Because the preflight failed, the browser terminated the request sequence immediately. The actual GET, POST, or PUT request was never transmitted to the server. You can inspect the failed OPTIONS transaction directly inside your browser's Network panel.

Decode the trailing clause

Match the specific clause at the end of the console error to find the exact misconfiguration on your server.

The rows marked no wrapper print directly after blocked by CORS policy: instead of inside the preflight wrapper. They mean the preflight answered 2xx with CORS headers, but the allow list omitted the method or header your request needs.

Fix the preflight response

The most frequent production cause is authentication middleware running ahead of CORS handling. Because browsers never send credentials such as cookies or the Authorization header on an OPTIONS preflight, auth middleware rejects the probe with status 401 or 403. Apply these changes to correct your preflight behavior.

1. Reorder server middleware

   Place your CORS handling middleware before authentication and authorization middleware so OPTIONS requests receive preflight headers before any auth checks run.

2. Exempt OPTIONS from auth checks

   Ensure your authentication handlers immediately skip requests that use the OPTIONS method.

3. Return an HTTP 2xx status

   Answer valid OPTIONS requests with status 204 No Content or status 200 OK along with your CORS allow headers.

4. Eliminate preflight redirects

   Verify that your client points to the canonical API endpoint, avoiding HTTP to HTTPS upgrades, apex to www changes, or missing trailing slashes that trigger 3xx redirects.

5. Configure origins and credentials accurately

   When sending cookies or authorization headers from the browser, echo the exact requesting origin in Access-Control-Allow-Origin and supply Access-Control-Allow-Credentials: true.

6. Expand allowed methods and headers

   Populate Access-Control-Allow-Methods and Access-Control-Allow-Headers to cover every method and custom header sent by the client application.

import cors from 'cors';
import express from 'express';

const app = express();

// CORS runs first and answers OPTIONS with a 204 before auth sees it.
app.use(
  cors({
    origin: 'https://your-site.com',
    credentials: true,
  }),
);

// Preflights carry no cookies or Authorization header, so any auth
// middleware mounted above the CORS layer 401s every OPTIONS request.
app.use(requireAuth);

app.post('/data', (req, res) => {
  res.json({ ok: true });
});

Verify the fix

Emulate the browser preflight call using curl. Include an Origin header and the Access-Control-Request-Method header to confirm that the server responds with a 2xx status and the required Access-Control-Allow-* headers.

$ curl -i https://api.example.com/data \
    -X OPTIONS \
    -H "Origin: https://your-site.com" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: content-type"

HTTP/2 204
access-control-allow-origin: https://your-site.com
access-control-allow-methods: POST
access-control-allow-headers: content-type

# The browser needs exactly this: a 2xx status plus the allow headers.

Good questions.