How to tell CORS blocking from a real server error

To tell CORS blocking from a real server error, compare the browser console, network response, and a non-browser request before changing headers.

CORS errors are often reported as “the API is down,” but the browser can block a response that the server actually returned. A server can also return a 500 while the console shows a CORS-looking message because the error response omitted CORS headers. The first task is to identify whether the request reached the server and what the server sent back.

Check the browser network tab for request method, origin, preflight OPTIONS request, response status, and response headers. Then make a curl or server-to-server request with similar headers. If curl succeeds but browser fails, the issue is likely CORS policy, credentials, allowed origin, allowed headers, or preflight handling. If both fail with the same status, the problem is probably server logic, authentication, routing, or upstream dependency.

Do not fix every CORS report by allowing all origins. That can turn a debugging shortcut into a security problem. Instead, record the expected origin, whether credentials are needed, allowed methods, allowed headers, and whether error responses also include the required CORS headers.

A good bug note says: browser blocked the response because the preflight failed, or server returned 500 and the error path lacked CORS headers. Those are different fixes. Naming the difference prevents random header changes.

How to tell CORS blocking from a real server error

// COMMENTS

ON THIS PAGE