Fix CORS Access-Control-Allow-Origin errors
A CORS message means the browser refused to expose a cross-origin response to page JavaScript. Identify whether the preflight or actual response failed before changing client code.
Confirm the two origins
An origin is the scheme, hostname, and port together. https://app.example.com and https://api.example.com are different origins, as are HTTP and HTTPS or two different ports. Record the page origin from the browser address bar and the final request URL after redirects. The API must make an intentional decision about that exact page origin.
Inspect preflight and response headers
Open the browser Network panel and look for an OPTIONS request before the failing request. JSON content types, authorization headers, custom headers, and non-simple methods commonly trigger this preflight. The response must allow the requesting origin, method, and requested header names. A 200 application response is not enough if the browser blocks it because the CORS headers are absent.
Copy the response fields into the HTTP Header Analyzer. It flags wildcard origins combined with credentials and reminds you to use Vary: Origin when a server dynamically selects one allowed origin. Check every response path, including authentication failures and proxy-generated errors, because a missing header on an error response can hide the useful body.
Fix the server, not the browser
Configure CORS at one trusted layer: the application, API gateway, or reverse proxy. Maintain an allowlist of complete origins and echo a value only after an exact match. Do not reflect any supplied Origin without validation. Avoid browser extensions, disabled web security, or an open relay proxy as production fixes; they remove the protection rather than establishing trust.
Credentials and caching
Cookies or HTTP authentication require the client’s credentials option and Access-Control-Allow-Credentials: true. In that mode the allow-origin value cannot be *. Cookies also remain subject to Secure, SameSite, domain, and path rules. If responses vary by origin, include Vary: Origin so a shared cache does not serve one tenant’s CORS decision to another.
Retest the real path
Retry from the actual frontend origin, clear only relevant cached responses, and inspect both OPTIONS and the real request. Test denied origins too. A safe configuration allows the required clients, rejects unknown origins, and never treats CORS as authentication; the API must still authorize every request.
Frequently Asked Questions
Can frontend JavaScript fix a missing CORS header?
No. The API or its trusted gateway must return the correct headers.
Can wildcard origins be used with credentials?
No. Credentialed requests require an explicit allowed origin.
Why does cURL work when the browser fails?
CORS is enforced by browsers, not terminal HTTP clients.