How to Fix: ‘blocked by CORS policy: No Access-Control-Allow-Origin header is present’

Quick Fix

If you control the backend, add the missing header to its responses (for example in Express: app.use(cors()), or manually set Access-Control-Allow-Origin: https://yourfrontend.com). If you do not control the backend, you cannot fix it from the browser side — instead route the request through your own backend proxy or server-side function.

1. Confirm it is really a CORS issue. Open DevTools > Network tab and check the failed request's response headers.
2. Add the correct header on the server for the exact origin (or * for public, credential-free APIs).
3. If it is a third-party API you do not control, call it from your own server/serverless function instead of directly from the browser.

Step-by-Step Guide

What this error means

This is not really a network failure — the request usually reaches the server and gets a response. A CORS error occurs when your browser blocks a response because the server didn't include the required permission headers, even though the request often completes successfully on the server. CORS doesn't prevent requests — it prevents your JavaScript from reading the response.

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls how web pages on one origin can request resources from a different origin, where an origin is defined by the combination of scheme, host, and port. The response to the CORS request is missing the required Access-Control-Allow-Origin header, which tells the browser whether the resource can be accessed by content operating within the current origin.

Important: CORS is enforced by the browser, but the fix is always on the server — the browser reads the response headers to decide whether your JavaScript is allowed to see the data, and no amount of frontend code can override a missing Access-Control-Allow-Origin.

Fix 1: Confirm the request/response in DevTools first

1. Open the Network tab in your browser's DevTools before reproducing the error.
2. Click the failed request and check its Response Headers for Access-Control-Allow-Origin. CORS errors in the browser console don't show the specific cause for security reasons — the Network tab is the only reliable place to see the actual headers exchanged.
3. Check for a preflight OPTIONS request. CORS relies on a mechanism by which browsers make a preflight request to the server, sending headers that indicate the HTTP method and headers that will be used in the actual request. If the OPTIONS request itself fails or is missing CORS headers, that is your root cause.

Fix 2: Add the header on your own server (if you control the backend)

1. Add the Access-Control-Allow-Origin header. Add the origin of the requesting site to the set of domains permitted access by adding it to the Access-Control-Allow-Origin header's value, for example Access-Control-Allow-Origin: https://example.com.
2. Use a wildcard only for public APIs. You can configure a site to allow any site to access it by using the * wildcard, but you should only use this for public APIs — private APIs should never use *, and should instead have a specific domain or domains set.
3. For credentialed requests (cookies/auth), reflect the origin dynamically. To allow a site to make CORS requests without using the wildcard (for example, to enable credentials), your server must read the value of the request's Origin header and use that value to set Access-Control-Allow-Origin, and must also set a Vary: Origin header so caches don't serve the wrong origin's response to someone else.
4. In Node/Express, use the official cors package: app.use(cors({ origin: 'https://yourfrontend.com' })) rather than hand-writing headers.
5. In Apache, add a line to the server's configuration within the appropriate Directory, Location, Files, or VirtualHost section, typically in a .conf file such as httpd.conf, or in an .htaccess file.
6. Never send more than one Access-Control-Allow-Origin header. Browsers expect only one Access-Control-Allow-Origin header in a response — if a server returns multiple headers, the browser cannot determine which origin is allowed and blocks the request, so configure the server to return a single header that dynamically matches the request's origin.

Fix 3: Check for a preflight/method/header mismatch

1. Verify allowed methods. The default cors package allows all methods like GET, POST, PUT, HEAD, PATCH; if you tighten security by specifying allowed methods, even if the origin matches, if the method is not allowed the preflight will fail and the actual request will be blocked.
2. Check custom headers you're sending (like Authorization) are included in Access-Control-Allow-Headers on the server.
3. If a custom response header reads as null in your JS, that's a different but related issue: by default browsers only expose a small set of CORS-safelisted response headers to JavaScript (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma) — any header outside that list is hidden unless the server explicitly opts in via Access-Control-Expose-Headers.

Fix 4: When you do NOT control the third-party server

1. Accept that you cannot fix it client-side. If the remote server is not under your control and does not include the Access-Control-Allow-Origin header, you cannot fix this error on the server side.
2. Build a small proxy/backend endpoint. Have your own server fetch the third-party API and return the data to your frontend — server-to-server requests are not subject to the browser's same-origin policy, since the restriction only applies to browser JavaScript.
3. Use a browser extension only for local development, never in production. Extensions such as CORS-unblock tools work by injecting the header client-side, but this only works on your own machine and cannot be relied on for real users or production sites.

Fix 5: Local file (file://) or localhost quirks

1. Run a local dev server instead of opening files directly. This error can occur when a request is made using a scheme other than HTTP or HTTPS, such as file:// — CORS policies apply only to HTTP(S) requests, so opening frontend files directly from your local filesystem can trigger this error, and running a local development server usually resolves it.
2. Treat localhost and 127.0.0.1 as different origins. Origin is determined by protocol, domain, and port — even small differences like localhost vs 127.0.0.1 or different ports make the origin different. Make sure your allowed origin list matches exactly what the browser address bar shows.

When to get different help

1. Third-party/vendor API with no CORS support: contact that provider's support or check their docs for an officially supported proxy or SDK — you cannot force their server to add headers.
2. Corporate or authenticated app with cookies breaking in Safari: this may be a browser privacy feature, not a config bug. Third-party cookie restrictions in Safari's ITP (Intelligent Tracking Prevention) can block credentialed CORS requests even with correct headers.
3. Security review needed: if you are about to widen a CORS policy for a production API handling user data, avoid a blanket wildcard with credentials enabled and instead validate origins against an allowlist before shipping.