Blocked by CORS policy? Find which header is missing and where.

It means the response your browser received had no Access-Control-Allow-Origin header at all, so the browser refuses to hand the response body to your JavaScript, even though the server may have processed the request correctly and even returned a 200. Either the server never sends the header (no CORS middleware, or it isn't wired into this route), or something in front of it, a proxy, CDN, load balancer, or an error-handling middleware, strips it before the response reaches the browser. It is not a case of the value being wrong: there is no value at all.

Because that request stops being a "simple request" the moment it carries a header outside the CORS-safelisted set (Accept, Accept-Language, Content-Language, Content-Type) or a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain. application/json and an Authorization header both push it into preflight territory: the browser sends an OPTIONS request first, and if that response is missing, returns a non-2xx status, or its Access-Control-Allow-Methods / Access-Control-Allow-Headers don't list your method and header, the browser blocks the real request before it's even sent. A plain GET or a form-encoded POST never triggers this, which is why it can look like "POST is broken" when it's really "the preflight for this POST is broken".

No. The Fetch/CORS spec forbids pairing the * wildcard with a credentialed request (cookies, or fetch with credentials: 'include'): when responding to a credentialed request, the server must specify an origin in Access-Control-Allow-Origin instead of specifying the * wildcard, and it must also send Access-Control-Allow-Credentials: true. If your request needs cookies or an Authorization header carried automatically, the server has to echo back the exact requesting origin (typically from an allow-list), not a wildcard, plus Vary: Origin so caches don't serve one origin's response to another.

CORS is a browser-enforced restriction, not a server-enforced one. Postman, curl, and server-to-server calls never apply the same-origin policy or send a preflight OPTIONS request, so they see the real response regardless of what CORS headers are present. Only a page running in a browser, calling a different origin via fetch/XHR, triggers CORS checks and preflights. If Postman gets a clean 200, your server logic is fine: the fix is entirely about which response headers your server sends back to a browser-originated request.

Express: app.use(cors({ origin: 'https://your-frontend.example', credentials: true })) using the cors package, mounted before your routes and before any auth middleware. FastAPI: app.add_middleware(CORSMiddleware, allow_origins=[...], allow_credentials=True, allow_methods=[...], allow_headers=[...]), noting that allow_origins can't be ["*"] together with allow_credentials=True. Django: add corsheaders to INSTALLED_APPS, put corsheaders.middleware.CorsMiddleware as high as possible in MIDDLEWARE, and set CORS_ALLOWED_ORIGINS. In every case the exact origin (not a wildcard, if you use cookies) and the ordering of middleware relative to auth checks are what most setups get wrong. The diagnosis tool above generates the specific snippet for your values.

No. Everything you type or paste, the error text, your request details, the response headers, stays in your browser tab and is never sent anywhere. The diagnosis runs entirely client-side against the values you enter; it never makes a request to your API to check anything live. Read doctor-cors.js directly, or check your browser's Network tab while using the tool, to verify.