Why does Access-Control-Allow-Origin '*' fail with credentials?

When a request includes credentials (cookies or HTTP auth), the browser forbids a wildcard Access-Control-Allow-Origin. You must echo the exact requesting Origin and also send Access-Control-Allow-Credentials: true. Returning '*' alongside credentials causes the browser to block the response.

When does the browser send a CORS preflight request?

A preflight OPTIONS request is sent for non-simple requests: any method other than GET, HEAD or POST, any custom request header, or a POST with a Content-Type other than the three form/text types. The browser asks permission before sending the real request.

What makes a CORS request simple (no preflight)?

A simple request uses GET, HEAD or POST, only CORS-safelisted headers (Accept, Accept-Language, Content-Language, Content-Type) and a Content-Type of application/x-www-form-urlencoded, multipart/form-data or text/plain. Anything else triggers a preflight.

How do I expose a custom response header to JavaScript?

By default JavaScript can only read CORS-safelisted response headers. To make a custom header like X-Total-Count readable, list it in Access-Control-Expose-Headers. Without that, fetch can see the header in DevTools but reading it from the Response object returns null.

What is the most dangerous CORS misconfiguration?

Reflecting any Origin (echoing the request Origin without an allow-list) together with Access-Control-Allow-Credentials: true. This lets any malicious site make authenticated cross-origin requests and read the responses, effectively bypassing the same-origin policy for logged-in users.

CORS Headers Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

CORS (Cross-Origin Resource Sharing) is the browser mechanism that lets a page on one origin make requests to a different origin in a controlled way. It works through a set of request and response headers, plus an optional preflight OPTIONS round-trip. This reference lists every header and explains the flow.

How it works

When JavaScript on https://app.example.com calls an API on https://api.example.com, the browser attaches an Origin header. For “non-simple” requests the browser first sends a preflight OPTIONS request carrying Access-Control-Request-Method and Access-Control-Request-Headers. The server must answer with matching Access-Control-Allow-* headers. Only if the response approves the method, headers and origin does the browser send the real request and expose the response to the script.

The preflight flow

Browser → OPTIONS /data
  Origin: https://app.example.com
  Access-Control-Request-Method: PUT
  Access-Control-Request-Headers: content-type, x-token

Server → 204 No Content
  Access-Control-Allow-Origin: https://app.example.com
  Access-Control-Allow-Methods: GET, PUT, DELETE
  Access-Control-Allow-Headers: content-type, x-token
  Access-Control-Max-Age: 600

If the response approves everything, the browser proceeds with the actual PUT. Access-Control-Max-Age lets the browser cache the preflight to skip repeats.

Notes and common mistakes

Never combine Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — browsers reject it. When you support credentials, echo the validated Origin from an allow-list and also add Vary: Origin so caches do not serve the wrong origin’s response. Reflecting any origin without validation is the classic exploitable CORS bug.