标签：#cors

The browser console showed exactly what CORS errors always show — a request blocked for violating the same-origin policy — except the response headers, visible in the network tab, clearly included Access-Control-Allow-Origin: * . The header the browser wanted was right there. The browser rejected the request anyway. The detail that's easy to miss in the network tab Chrome's network inspector, by default, coalesces duplicate header names into a single display line — so Access-Control-Allow-Origin: * shown once in the UI can actually mean the header was sent twice by the server, and the browser is showing you a merged, deduplicated view rather than the literal wire response. curl -s -D - https://api.example.com/data -o /dev/null | grep -i access-control Access-Control-Allow-Origin: * Access-Control-Allow-Origin: https://app.example.com Two separate headers, both valid individually, sent by two different layers that each thought they were the one responsible for CORS: our nginx reverse proxy had a blanket add_header Access-Control-Allow-Origin *; for general API access, and the application server behind it independently set a specific origin for authenticated routes. Neither config was wrong on its own. Together, they produced a response with the header appearing twice — and per the Fetch spec, a response with multiple Access-Control-Allow-Origin values is treated as invalid, so the browser blocks the request rather than guessing which one you meant. Why this is worse than a missing header A missing CORS header fails immediately, obviously, the same way every time. A duplicate header fails in a way that looks, from the response body alone, like the header is present and correct — because it is present, twice, which is precisely the state that trips the spec's validation. Every piece of evidence you'd normally check says "this should work," and it still doesn't. The fix Removed the blanket nginx header and let the application server be the single source of truth for COR

CORS Errors Explained: Every Fix, Every Framework (2026 Guide) TL;DR — A CORS error means the browser blocked a cross-origin request because the server did not explicitly allow it. The fix is always server-side : return the correct Access-Control-Allow-Origin header from your backend. This guide covers every CORS error type, a step-by-step diagnosis flow, and copy-paste fixes for Express, FastAPI, Next.js, nginx, Cloudflare Workers, and Vercel. You can inspect and validate your CORS headers live with the CORS Header Checker — no curl, no Postman, no install. What CORS Actually Is (and Why the Browser Enforces It) The Same-Origin Policy (SOP) is a browser security rule: JavaScript running on https://myapp.com can only read responses from requests made to the same origin — same scheme, same host, same port. Everything else is cross-origin. CORS — Cross-Origin Resource Sharing — is the mechanism that lets servers selectively relax the Same-Origin Policy. A server adds HTTP headers to its responses that tell the browser: "it is okay to share this response with code from origin X." Without those headers, the browser reads the response, then silently discards it and throws a CORS error into your console. Three things to burn into memory before you read further: CORS is enforced by the browser, not the server. curl and Postman do not check CORS — they always get the response. Only browsers do CORS. If your API works in Postman but fails in the browser, CORS is almost certainly why. The fix is server-side, always. Browser extensions that "disable CORS" are masking the problem in your local browser only. They break for every real user. Never ship code that depends on them. Preflight is a separate request. For non-simple requests (anything with a custom header, a JSON body, or methods other than GET/POST), the browser sends an OPTIONS request first to ask for permission. Your server must handle this correctly. The Four CORS Error Types — Diagnosed from the Console Message Err