Debug CORS Errors by Reading the Request and Response Headers

A CORS error often looks like a browser problem, but the browser is enforcing a contract between an origin, a request, and a server response. The fastest way to fix it is not to add a wildcard header at random. It is to identify the exact request the browser blocked, read the request headers, and compare them with the server response. This keeps a local development shortcut from accidentally becoming a production security hole. ## Identify the request that actually failed Open the browser network panel, preserve the log, and reproduce the action once. Find the request with a failed status or an `OPTIONS` method. Record the page origin, the request URL, the HTTP method, and any custom headers. A request from `https://app.example.com` to `https://api.example.com` is cross-origin because the host differs, even though both use HTTPS and share a parent domain. Ports matter too: a local frontend on port 3000 and an API on port 8000 are separate origins. The browser may send a preflight request before the real request when the method or headers are not considered simple. That preflight asks whether the server permits a particular origin, method, and header set. If the preflight fails, the browser never sends the intended write request. Treat `OPTIONS` as a useful diagnosis rather than an unexpected extra call. ## Match the server response to the browser's question For a successful cross-origin response, `Access-Control-Allow-Origin` must match the caller's origin or follow a safe policy for the request. If the browser sends credentials such as cookies, the response cannot use a wildcard origin. It also needs `Access-Control-Allow-Credentials: true`, and the frontend request must explicitly opt into credentials. For preflighted requests, the response must allow the requested method and headers, usually through `Access-Control-Allow-Methods` and `Access-Control-Allow-Headers`. Compare names rather than guessing. If the browser requests `authorization, content-type`, allowing only `Content-Type` will still fail. If a proxy strips the CORS headers from error responses, a useful API error may appear as a generic CORS failure. Check successful, failed, and redirected responses through every layer: application server, reverse proxy, CDN, and authentication gateway. ## Avoid fixes that widen access without intent Do not reflect every incoming `Origin` header unless the endpoint is deliberately public and protected in another way. Use an allowlist of known web origins for authenticated APIs. Keep development origins separate from production origins, and do not rely on a regex that accepts lookalike domains. CORS does not replace authentication or authorization. It only controls which browser pages may read a response. The CalcSnippets HTTP Header Parser is useful when you need to turn a copied response into a readable object during an incident. Use it to inspect header names and values, then make the policy change where the server owns it. A reliable CORS fix makes the allowed caller, method, credentials, and headers explicit, and it is verified from a real browser after deployment.