No Access-Control-Allow-Origin Header: Causes and Fixes

One of the most frequent browser console errors encountered in web development is: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Core role of Access-Control-Allow-Origin

Access-Control-Allow-Origin is an HTTP response header that must be sent by the server or API gateway. When a web browser executes cross-origin JavaScript requests, it requires this header in the server’s response. If the header is missing, the browser intercepts the network response and blocks your client-side JavaScript code from accessing the data.

Because this is a server response header, you cannot resolve the issue by modifying frontend client request headers alone. The configuration must be added or corrected on the API server.

What the missing header means

When client code on https://app.example.test makes an API call to https://api.example.test, the browser sends an Origin: https://app.example.test request header.

The browser expects the server response to contain:

Access-Control-Allow-Origin: https://app.example.test

If the server omits this header entirely:

• The network connection to the server was established.
• The server processed the request and sent back an HTTP response.
• The browser received the HTTP response, but because Access-Control-Allow-Origin was missing, the browser’s Same-Origin Policy enforcement prevented the JavaScript runtime from accessing the response body and headers.

Why Postman can still receive a response

Developers often find that calling the same endpoint in Postman, Insomnia, or curl succeeds and displays the expected JSON data.

This occurs because non-browser HTTP tools do not enforce the browser’s Same-Origin Policy. Postman acts as a direct HTTP client; it sends the request and displays whatever the server returns, regardless of whether CORS headers are present. A successful response in Postman verifies that the server endpoint is functional, but it does not test browser CORS compatibility.

Common response-side causes

Server Omits CORS Headers Completely

The backend server or API route does not include CORS middleware or headers in its response, causing the browser to block JavaScript access.

Origin Header Mismatch in Allowed Origins

The backend dynamically checks the Origin request header against an allowlist, but the requesting domain is missing or misspelled, leading to omitted CORS headers.

Reverse Proxy or Gateway Strips Response Headers

An intermediate reverse proxy, load balancer, or CDN strips or replaces CORS headers before forwarding the response to the client.

Unhandled Server Error Bypasses CORS Pipeline

An unhandled exception produces a 500 Internal Server Error before reaching the CORS response filter, resulting in an error response lacking CORS headers.

What to inspect in browser DevTools

To inspect the failure accurately:

1. Open Browser DevTools and navigate to the Network tab.
2. Locate the failed request entry and click on it.
3. Check the Request Headers section to see the exact Origin header value sent by the browser.
4. Check the Response Headers section to confirm whether Access-Control-Allow-Origin is present and what value it contains.
5. Check the Status Code to see if the server returned an error code (such as 500 or 404) rather than 200 OK.

What to compare before changing code

Before making changes to server configuration:

• Compare exact origin strings: An origin consists of scheme, hostname, and port. Verify that https://app.example.test is not being compared against http://app.example.test or https://app.example.test:8080.
• Check credential requirements: If your frontend request uses credentials (cookies or HTTP authorization), the server must return an explicit origin in Access-Control-Allow-Origin (e.g., https://app.example.test) rather than a wildcard *, along with Access-Control-Allow-Credentials: true.

Safe server-side ownership guidance

Resolving missing CORS headers requires changes on the server infrastructure:

• Configure CORS at the API server or gateway: Ensure the server or reverse proxy adds the Access-Control-Allow-Origin header for authorized requesting origins.
• Do not use browser extensions or public proxy services: Disabling browser security checks or funneling user traffic through third-party CORS proxies creates severe security vulnerabilities and is unsuitable for production applications.
• Maintain origin allowlists: For private APIs, maintain an allowlist of trusted origins rather than using indiscriminate wildcards where sensitive user data is handled.

How to verify the fix

Inspect server response headers using curl with an explicit simulated origin:

curl -i -H "Origin: https://app.example.test" https://api.example.test/v1/resource

Confirm that the server returns Access-Control-Allow-Origin: https://app.example.test in the response headers, then test the request from your browser frontend.

Key takeaway

Access-Control-Allow-Origin is an HTTP response header that must be provided by the server. When missing, the browser protects the user by preventing client JavaScript from reading the response. Fix the issue by configuring CORS on the backend or reverse proxy, verifying that the allowed origin matches the requesting frontend domain.