CORS FAQ: Practical Answers for Browser API Requests
By Ankit Jain · Updated
Quick answers about CORS errors, frontend fixes, Postman, no-cors, preflight, cookies and safe server configuration.
What is a CORS error?
The browser could not grant your JavaScript access to a cross-origin response under the CORS checks. Inspect Network to distinguish a rejected preflight, an unreadable actual response, and an underlying network failure. See the introduction.
Can I fix CORS only in the frontend?
You can correct an unintended URL, header, method, or credentials mode. Granting response permission requires the API or gateway to return the right headers. Adding Allow-Origin to request headers does not do that. See who controls each header.
Why does Postman work when my browser fails?
Native Postman or curl can reach an API without enforcing browser response-access permission. Compare the actual requests, including cookies, Origin, preflight, and redirects. See Postman versus the browser.
Does mode: no-cors fix it?
No. A cross-origin no-cors response is normally opaque: its body, real status, and headers are not readable by JavaScript. It is not a solution for an app that needs API JSON. See opaque responses.
Do credentials always cause preflight?
No. A GET with credentials: include and only safelisted headers can be simple. Authorization, JSON Content-Type, or a non-safelisted method commonly trigger preflight instead. See request types.
What is the fetch credentials default?
same-origin. For a cross-origin cookie session, use include, configure exact approved-origin and credentials permission, and verify cookie eligibility separately. See credentials and cookies.
Can Allow-Origin contain several domains?
No. It must return one valid origin or an appropriate wildcard. For multiple approved origins, select the matching origin per response and use Vary: Origin. See invalid and duplicate values.
When is wildcard origin permission appropriate?
For intentionally public response data that does not need credentials mode include. It does not work for include-mode response access. Authentication remains necessary for private APIs. See CORS configuration risks.
Does OPTIONS need my session cookie?
A CORS preflight normally does not carry it. Process permission before an auth layer that requires the cookie, then authenticate and authorize the actual request. See preflight.
OPTIONS succeeds. Why does fetch still fail?
The actual response needs independent origin permission and credential permission where applicable. It may be a 401, redirect, or proxy error that omits those headers. See error responses.
Why can DevTools see a header that JavaScript cannot read?
After valid CORS permission, only safelisted response headers and deliberately exposed extra headers are readable. Add Access-Control-Expose-Headers for the extra header you need. Set-Cookie cannot be exposed this way. See the header reference.
Does CORS prevent CSRF or authenticate my API?
No. Some cross-origin writes can reach a server even when the response is unreadable. Keep authentication, authorization, and dedicated CSRF defenses for cookie-authenticated writes. See CORS versus CSRF.
Are two subdomains the same origin?
No, their hostnames differ. They can still be same-site for cookie rules when the scheme and registrable domain match. See origin versus site.
Why does localhost work but 127.0.0.1 fail?
The hostnames differ, so the origins differ. A different development-server port also creates a different origin. Approve the actual intended frontend origins. See origin mismatch.
Why does CORS fail only after deployment?
Compare browser-facing responses through the proxy and CDN with direct application responses. Look for duplicate header writers, cached permission for a different origin, redirects, and gateway errors. See proxy and cache problems.
Can a CORS tester prove my frontend works?
A remote probe can inspect captured headers; it does not use your browser’s cookies or prove browser connectivity. Local header analysis depends on accurate request conditions. Verify from the real frontend. Read the tester’s limits.
Is Google OAuth origin_mismatch a CORS error?
It is an OAuth client configuration error when reported by the sign-in service. Check authorized JavaScript origins for the exact page origin; redirect URI settings are separate. Changing your API’s CORS response headers will not fix that client configuration. See the distinction.
Where should I start debugging?
Record origin, URL, method, headers, and credentials mode. Inspect OPTIONS if required, then the actual response. Identify the layer producing the failing response and verify the smallest safe fix. Follow the debugging workflow.