You hit “blocked by CORS policy” in the browser console and your fetch request fails. A CORS error means the browser asked the server for permission to share a response across origins, and the server did not return the right Access-Control-Allow-Origin header. The fix is almost always on the server, not in your front-end code.
What CORS actually is
CORS (Cross-Origin Resource Sharing) is a browser security feature built on the same-origin policy. By default, a page on https://app.example.com cannot read a response from https://api.other.com unless that other server explicitly allows it. The browser enforces this, not the server, which is why the request often reaches the server fine but the browser still blocks the response from your JavaScript.
So a CORS error is not your code being wrong. It is the browser protecting users, waiting for the API to say “yes, this origin may read my data.”
Why the CORS error happens
For “simple” requests (a basic GET or POST), the browser sends the request and then checks the response for an Access-Control-Allow-Origin header matching your origin. If it is missing or wrong, you get the error.
For anything non-simple (custom headers, PUT, DELETE, application/json bodies), the browser first sends a preflight OPTIONS request asking what is allowed. The server must answer that preflight with the right headers before the real request is ever sent. A failing preflight is one of the most common causes of CORS errors.
The key response headers are:
- Access-Control-Allow-Origin: which origin may read the response.
- Access-Control-Allow-Methods: which HTTP methods are permitted.
- Access-Control-Allow-Headers: which request headers are permitted.
- Access-Control-Allow-Credentials: whether cookies or auth headers may be sent.
How to fix CORS errors the right way
The correct fix is to configure the server that owns the API to send proper CORS headers for your origin. Do not disable browser web security, and do not route your traffic through a random public proxy. Those hide the problem and create real security holes.
To check that your header combination is valid before you ship it:
- Open the CORS Header Validator.
- Paste or enter the CORS headers your server returns (or the ones you plan to set).
- Enter the request origin and method you are testing.
- Check the combination and read which headers are missing or conflicting.
If you control the API, set Access-Control-Allow-Origin to your exact origin, list the methods and headers your client uses, and make sure the server answers OPTIONS preflight requests with a 2xx status and the same headers.
The Allow-Origin wildcard trap
The biggest security mistake is pairing Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. The browser will reject that combination outright, because a wildcard origin plus credentials would let any site read authenticated responses. When you send credentials, you must echo back a specific origin, never *. The CORS Header Validator flags this exact conflict so you catch it before it ships.
Related tools
- Security Headers Generator: build a full set of response headers, including CORS, in one place.
- CSP Builder: craft a Content-Security-Policy that pairs well with your CORS setup.
- HTTP Header Analyzer: inspect the headers a server already returns.
Fix CORS on the server, name your exact origin, and never disable browser security to make the error go away.