"Has Been Blocked by CORS Policy": Every Variant and Its Fix

Chrome and Edge print one Console line per blocked request, built in Blink's cors_error_string.cc:

Access to fetch at 'https://api.example.com/v1/items' from origin 'https://app.example.com'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

«fetch» becomes «XMLHttpRequest» or «font» depending on what made the request, and the text after CORS policy: is the actual reason. Firefox words the same check as Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ... (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200. (security.properties).

CORS is enforced by the browser, not the server. The request usually reached the API and got an answer; the browser then refused to hand that answer to a script from another origin (scheme, host and port must all match to count as the same origin). The script only receives TypeError: Failed to fetch. That is also why the same call works in curl or Postman: they do not enforce CORS at all.

A preflight is an automatic OPTIONS request the browser sends before a cross-origin call that uses a method other than GET, HEAD or POST, a Content-Type such as application/json, or custom headers like Authorization. Note that Access-Control-Allow-Headers: * does not cover Authorization: Firefox already warns that it must be listed explicitly. More on preflights: CORS preflight.

Most real-world cases are a layer problem rather than a missing line of code. The application sets the headers, but nginx answers OPTIONS itself with 405, an authentication layer returns 401 to the preflight because browsers never send credentials on it, or an error page from the proxy (502, 504, 413) goes out without any CORS headers, so a backend failure surfaces as a CORS error. In nginx, add_header only applies to 2xx and 3xx responses unless you add always:

location /v1/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin  $http_origin always;
        add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE' always;
        add_header Access-Control-Allow-Headers 'Content-Type, Authorization' always;
        add_header Access-Control-Max-Age 600 always;
        return 204;
    }
    add_header Access-Control-Allow-Origin $http_origin always;
    add_header Vary Origin always;
    proxy_pass http://app;
}

Echoing $http_origin as shown allows every origin; in production, map it against an allow list first. A CDN that caches the response must vary on Origin, or one site's allowed origin is served to another.

1. Copy the exact reason from the Console. The table above maps each wording to one change.
2. See what the server returns for your origin:

   curl -sS -D - -o /dev/null https://api.example.com/v1/items \
     -H 'Origin: https://app.example.com'

3. Replay the preflight with the method and headers your code sends:

   curl -sS -D - -o /dev/null -X OPTIONS https://api.example.com/v1/items \
     -H 'Origin: https://app.example.com' \
     -H 'Access-Control-Request-Method: POST' \
     -H 'Access-Control-Request-Headers: content-type,authorization'

   Expect a 2xx status, your origin in access-control-allow-origin, and the method and headers in the allow lists.
4. Make errors carry the headers too. Trigger a 404 or 401 with the same Origin header and check that the allow header is still there.
5. For cookies or HTTP auth, return the exact origin (never *), add Access-Control-Allow-Credentials: true, and set credentials: 'include' on the client.
6. If you do not control the API, call it from your own backend and return the data from your origin. mode: 'no-cors' does not fix it: it returns an opaque response your script cannot read (MDN).

Background on the header model: CORS explained and how to configure CORS.

• Adding CORS headers in front-end code. Access-Control-Allow-Origin is a response header; setting it on the request does nothing except trigger a preflight.
• Fixing http://localhost:3000 but deploying from https://app.example.com. The origin is compared exactly, including scheme and port.
• A trailing slash in the allowed origin (https://app.example.com/). An origin has no path.
• Disabling web security in the browser to test. It hides the error on one machine and proves nothing about production.
• Allowing * on an API that relies on cookies. Browsers reject that combination, and it is unsafe on private APIs.

curl -sS -D - -o /dev/null -X OPTIONS https://api.example.com/v1/items \
  -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: POST' \
  | grep -i '^access-control'
# access-control-allow-origin: https://app.example.com
# access-control-allow-methods: GET, POST, PUT, DELETE

Then reload the page: the Network tab should show the OPTIONS request with a 2xx status followed by the real request, and the Console should stay clean. The CORS checker sends the simple request and the preflight for any URL and grades the answer.

• TypeError: Failed to fetch — what your script sees after the block
• Fixing CORS preflight — OPTIONS handling in detail
• CORS — the header model in one page
• ERR_BLOCKED_BY_RESPONSE — CORP and frame headers, not CORS
• Mixed content — an http:// API called from an https:// page