CORS header 'Access-Control-Allow-Origin' missing

The exact console message

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.example.com/data. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Firefox prints this wording when the response to a cross-origin request lacks the Access-Control-Allow-Origin response header, or when the header value does not match the page origin. Chrome prints No 'Access-Control-Allow-Origin' header is present on the requested resource for the same underlying failure.

What the browser is telling you

The browser executed the request and examined the resulting response headers against the Same-Origin Policy. It checked for an Access-Control-Allow-Origin header, found no acceptable origin match, and prevented your JavaScript code from accessing the response.

Because this check occurs in the browser after the transport layer finishes, your developer tools Network panel may still display a status code like 200 and show the complete payload. Despite this, the browser runtime isolates the data from client scripts.

Common causes

• The backend service never implemented CORS headers, returning raw data without any Access-Control-Allow-Origin header on responses.
• The backend echoes an explicit origin that does not match the requesting page scheme, host, and port, or returns a wildcard while the request includes credentials.
• The application framework executes CORS middleware only on 2xx responses, causing 4xx and 5xx error responses to omit the Access-Control-Allow-Origin header.
• The request triggers a redirect, such as an HTTP to HTTPS upgrade or a trailing slash normalization, and the intermediate redirect response omits CORS headers or drops preflight parameters.
• The console displays Status code: (null), which indicates that no HTTP response reached the browser due to a DNS failure, a TLS certificate error, a refused connection, or a browser extension blocking the request.

Fix the missing header

The required correction depends on whether you maintain the destination server, whether the failure happens on error statuses, or whether you are accessing an unmodifiable third-party API.

1. Add the origin header on your API

   If you maintain the API backend, configure it to return an Access-Control-Allow-Origin header. The value must match the incoming Origin header exactly, including scheme, host, and port, or be an asterisk wildcard for public, uncredentialed requests.

2. Ensure error responses retain CORS headers

   Reorder server middleware so CORS handling wraps all error handlers. When using nginx, append the always parameter to the add_header directive, which forces nginx to send the header on 4xx and 5xx error responses instead of stripping it.

3. Send requests directly to the final canonical URL

   Eliminate redirect chains by requesting the exact endpoint directly. Update URLs to match the canonical protocol, domain, and trailing slash structure, because browsers do not follow redirects during preflight requests.

4. Route third-party public APIs through a CORS proxy

   If you cannot modify a third-party public API, route GET and HEAD requests through a CORS proxy like https://proxy.cors.dev/. This approach applies solely to public data, as proxies must never handle private user data, authorization tokens, or credentials.

server {
    listen 443 ssl;
    server_name api.example.com;

    location / {
        # Without always, add_header skips 4xx and 5xx responses,
        # so your error answers fail the browser CORS check.
        add_header Access-Control-Allow-Origin $cors_origin always;
        add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;

        proxy_pass http://localhost:3000;
    }
}

Verify the fix

Use curl to inspect response headers from outside the browser. Supply an Origin header matching your site, and test both a valid endpoint and a non-existent path to verify that error responses also return the header.

$ curl -i https://api.example.com/data \
    -H "Origin: https://your-site.com"

HTTP/2 200
access-control-allow-origin: https://your-site.com

$ curl -i https://api.example.com/does-not-exist \
    -H "Origin: https://your-site.com"

HTTP/2 404
access-control-allow-origin: https://your-site.com

# If the header is missing on either status, that response is what Firefox blocks.

Good questions.