CORS works until you include credentials.

Use the page’s exact origin.

An origin includes scheme, hostname and port. Different ports are different origins. Compare the page origin with Access-Control-Allow-Origin on the API response, not just with a deployment environment variable. The allowed origin must not include a path or trailing slash, and a comma-separated list of origins is not valid.

Use the CORS header checker with copied headers. It checks the actual response and, optionally, the OPTIONS status, method and requested header names. It never requests your endpoint or uploads the pasted headers.

Configure the two sides.

A cross-origin fetch that needs cookies must request credentials. The server must allow the explicit trusted origin and credentials. Do not reflect any Origin value without checking an allowlist.

// Browser, for an API you trust:
fetch("https://api.example.com/account", {
  credentials: "include"
});

// Corresponding API response headers:
// Access-Control-Allow-Origin: https://app.example.com
// Access-Control-Allow-Credentials: true
// Vary: Origin

This only addresses the origin and credential part of the exchange. CORS is not authentication or CSRF protection.

Inspect OPTIONS separately.

Check whether the browser made a preflight request and whether it succeeded. Requested methods and headers must be permitted. Authentication middleware that redirects or rejects every OPTIONS request can block the real request before it starts.

Do not add mode: "no-cors" as a workaround. It does not give your code a normally readable cross-origin response.

A 204 preflight can still block Authorization.

A JSON POST with an Authorization header typically causes a preflight. In the Network panel, select OPTIONS and find Access-Control-Request-Headers. A response can return 204 and still omit a required header:

// OPTIONS request headers:
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

// OPTIONS response, still blocked:
HTTP/2 204
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type

Authorization is missing from the allowed headers. It must be named explicitly, even when Access-Control-Allow-Headers contains a wildcard. For an origin you intend to trust, the response would need:

Access-Control-Allow-Headers: Content-Type, Authorization

Open the checker and select Try example to reproduce this case. Add Authorization to the OPTIONS response’s allowed headers, then check again. If OPTIONS prevented the actual request, leave Actual response headers empty until that request runs.

With fetch credentials set to include, wildcards in allowed methods and headers do not stand for every method or header. GET, HEAD and POST have separate safelisted-method rules; use the browser’s actual requested header names instead of guessing from the method alone. See the Fetch preflight algorithm.

Check the real response after OPTIONS passes.

A successful preflight permits the browser to send the request. The actual response must still contain the correct allowed origin and credential header. Check error responses too: a 401 without CORS headers can hide the useful authentication error from your frontend.

If behavior changes after a configuration update, inspect cached preflight responses and your CDN’s variation by Origin. Do not treat a copied-header check as proof that the deployed browser journey now works. Reproduce the request in a supported browser and inspect the resulting response.

Then inspect cookie policy.

If the response is allowed but no session reaches the server, inspect cookie storage and the outgoing request. SameSite rules and third-party cookie restrictions still apply. Use the cookie troubleshooting guide for that separate branch.

Reference: MDN’s CORS guide. Test in the browser you support, including a signed-out session.