What is a CORS error, and how do you fix it?

What a CORS error means

Browsers follow the same-origin policy: a script on https://app.example.com may not read responses from https://api.service.example unless that server says it may. CORS, Cross-Origin Resource Sharing, is how a server says so, with response headers such as Access-Control-Allow-Origin. If the header is missing or does not match your origin, the browser blocks your code from reading the response and logs an error like this:

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

CORS is enforced by the browser only. The same request from curl or a server works, which is why it confuses so many people.

Why it happens, most likely first

• The API you call does not support browser requests at all and expects to be called from a server.
• Your own API does not send CORS headers, or sends them only for some routes or only on success.
• The preflight request fails. Requests with JSON bodies, custom headers or methods like PUT trigger an OPTIONS request first, and the server must answer it with the right headers.
• You send cookies or credentials, and the server answers with a wildcard origin, which browsers reject for credentialed requests.
• The server errors out, and the error response has no CORS headers, so a 500 shows up as a CORS error.

How to fix it

• If you control the API, allow your exact frontend origin, answer OPTIONS preflights, and add the headers to error responses too:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Vary: Origin

• If it is a third-party API that does not allow browsers, call it from your own backend or a serverless function and have the frontend call that. This also keeps the API key out of the browser.
• In development, use your dev server's proxy so frontend and API share an origin.
• For cookies across origins, set Access-Control-Allow-Credentials: true with a specific origin, never a wildcard.

Do not fix CORS with a browser extension, a public CORS proxy or mode no-cors. The extension only works on your machine, a public proxy sees all your traffic, and no-cors gives you a response you cannot read.

The security side

CORS protects users, not servers. Allowing every origin to read responses that depend on a user's cookies lets any website read that user's data. Reflecting whatever Origin header arrives back into Access-Control-Allow-Origin has the same effect. Allow the specific origins you own.

AI-built apps and CORS

AI app builders often generate frontend code that calls an AI or payment API directly from the browser. That fails with CORS, and if it is made to work, it exposes the API key to every visitor. The right structure is always the same: the browser calls your backend, your backend calls the third party with the secret.

What a scan can and cannot tell you

WebAuditOS reports a wildcard Access-Control-Allow-Origin as a warning, and a wildcard combined with credentials as a failure. It also checks Cross-Origin-Resource-Policy and records JavaScript console errors, where CORS failures appear.

It cannot tell whether a specific allowed origin is safe, and a server that reflects any origin back can pass. It also only sees the endpoints its crawl touches.

No CORS header at all is not graded, because most pages do not need one. Only APIs called from other origins do.

Short answers

Why does it work in Postman but not in the browser? CORS is enforced only by browsers.

Can I fix CORS in my frontend code? No. The server being called has to allow your origin.

Is Access-Control-Allow-Origin: * safe? For public, cookie-free data, yes. Never with credentials.

Why do I get a CORS error on a 500? Error responses often lack CORS headers, so the browser reports CORS instead of the real error.