Code Beautifier
CORS credentials with wildcard

Fix CORS wildcard "*" with credentials: include

Browsers block a response that pairs Access-Control-Allow-Origin: * with cookies or credentials. The console error, why the rule exists, and the fix.

Input that triggers it

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Set-Cookie: session=abc123; Path=/; HttpOnly; Secure
Open HTTP Headers & Security Inspector on its own page
Draft saved locally.

Local workspace

Named projects in IndexedDB · Local only — never synced to our servers. Worksp…

Open manager

Batch workspace

Format multiple files locally in one run.

text
json

What the error means

The browser console reports it as: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The request was made with credentials — cookies, an Authorization header set by the browser, or fetch(..., { credentials: "include" }) — and the server answered with Access-Control-Allow-Origin: *. The CORS specification forbids that combination, so the browser discards the response and the JavaScript sees a network error, even though the server returned 200.

The example response is exactly this shape: a wildcard origin, Allow-Credentials: true, and a cookie being set. Paste it into the inspector above and the CORS check reports the conflict.

Why it happens

  • A permissive CORS configuration (*) chosen during development, combined later with cookie-based sessions.
  • Access-Control-Allow-Credentials: true added to fix a different error, without changing the origin header.
  • A CDN or proxy that injects Access-Control-Allow-Origin: * on every response regardless of what the application sends.
  • A framework default: several CORS middlewares emit * when no origin list is configured.

The rule exists because credentials make a response personal. A wildcard would let any website on the internet read a logged-in user's data from your API via their browser; requiring an explicit origin forces the server to state which sites it trusts.

How to fix it

  1. Keep a list of allowed origins on the server. For each request, compare the incoming Origin header against the list, and if it matches, send that exact value back: Access-Control-Allow-Origin: https://app.example.com.
  2. Add Vary: Origin so that caches do not serve one origin's response to another.
  3. Keep Access-Control-Allow-Credentials: true; it is required for the browser to expose the response when credentials were sent.
  4. If the endpoint is genuinely public and needs no cookies, do the opposite: keep * and make the client stop sending credentials (credentials: "omit", the fetch default).

A corrected response:

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

If it still fails

  • Preflight requests (OPTIONS) need the same headers, plus Access-Control-Allow-Methods and Access-Control-Allow-Headers; a correct GET response with a wrong preflight still fails.
  • Never reflect the Origin header blindly without checking the list; that is equivalent to * with credentials and defeats the protection.
  • Reproduce the request outside the browser with cURL to Fetch to compare what the server sends with what the page receives; the headers the inspector grades are the ones the browser is enforcing.

Related errors