A cross-origin fetch to your API worked until you added credentials: 'include' so the session cookie would be sent; now the browser rejects the response and complains about the wildcard in Access-Control-Allow-Origin. What must the API return instead, and why does '*' stop being acceptable once credentials are involved?

## Two separate gates A credentialed cross-origin call has to clear two doors, and confusing them is the usual source of a wasted afternoon. **Gate one: will the browser attach the credential?** By default `fetch` uses `credentials: 'same-origin'`, meaning cookies ride along on same-origin requests and are omitted cross-origin. Setting `credentials: 'include'` asks for them cross-origin too. (`XMLHttpRequest` spells the same request as `xhr.withCredentials = true`.) Whether the cookie is actually attached also depends on how the server originally set it — a cookie sent in a cross-site context must be marked `SameSite=None` and `Secure`, and browsers additionally apply third-party cookie restrictions that may drop it regardless. If this gate fails you do not get a CORS error at all; you get a clean 401 or an anonymous response, because the API simply never saw a session. **Gate two: may the page read the response?** This is where the wildcard rule bites, and it produces a console message rather than a status code. ## What the response must contain For a credentialed request the browser requires both of: - `Access-Control-Allow-Credentials: true` - `Access-Control-Allow-Origin: <the exact origin string the browser sent>` ``` Origin: https://app.example.com (request, set by the browser) Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true ``` The match is a literal string comparison. `https://app.example.com` does not match `https://app.example.com/` with a trailing slash, nor `http://app.example.com`, nor a different port. And in credentialed mode `*` is not merely discouraged, it is treated as no permission at all — as are `*` values for `Access-Control-Allow-Headers` and `Access-Control-Allow-Methods`. ## Why the wildcard is banned here `Access-Control-Allow-Origin: *` is a public statement: *any* origin may read this resource. That is a reasonable thing to say about a public JSON feed, because the response is identical for everyone and contains nothing the reader could not fetch themselves. Add cookies and the statement becomes false. The response is no longer public — it is *this user's* data, computed from the session the browser attached automatically. If the wildcard were honoured, any page the user visited could run `fetch('https://api.example.com/me', { credentials: 'include' })` and read their profile, their inbox, their account balance. The user's browser supplies the authentication just by being logged in; the wildcard would supply the read permission. Banning that combination forces the server to name each origin it trusts with a user's session, which is a decision someone has to make consciously rather than one that falls out of a permissive default. This is also why the reflexive fix — "echo whatever is in the `Origin` header back" — deserves care. Reflecting the origin unconditionally *is* a wildcard, written in a way that also satisfies the credentialed rule; it re-opens exactly the hole the rule closes. Reflection is only safe when it is gated on an allow-list of origins you actually trust. ## Diagnosing it from the frontend The symptom pattern is distinctive: the call worked, you turned on credentials, and now the console names the wildcard while the Network panel shows the request completing normally with a 200. That combination says the server computed a fine response and the browser refused to hand it over. Things to check, in order: 1. Does the response carry `Access-Control-Allow-Credentials: true` at all? Many CORS middlewares require it to be enabled explicitly. 2. Is `Access-Control-Allow-Origin` the exact string in your `Origin` request header — no trailing slash, right scheme, right port? 3. Was a cookie actually sent? Look at the request's headers in the Network panel. An empty `Cookie` header means gate one failed, and no amount of CORS configuration will help. 4. Are you sure you need credentials? If the API authenticates with a bearer token in an `Authorization` header rather than a cookie, you do not need `credentials: 'include'` — but the header itself will make the browser check permission in advance, which is a different conversation. ## The pattern to remember Uncredentialed cross-origin reads are about a *resource* being public. Credentialed cross-origin reads are about a *relationship* between two specific origins. The wildcard can only express the first, which is precisely why the browser refuses to let it stand in for the second.