CORS Cross Origin
Wildcard with Credentials
Credentials Not SupportedReviewed for reference consistency: August 11, 2026
the server used a wildcard origin while the request includes cookies.
What Credentials Not Supported Means
The Credentials Not Supported error on the CORS Cross Origin indicates wildcard with credentials — the server used a wildcard origin while the request includes cookies.. This typically occurs due to the frontend fetch() or xmlhttprequest is configured with 'credentials: include' (intentionally sending cookies or http basic auth)..
Browsers forbid sending cookies or HTTP auth to a server using a wildcard origin. Chrome displays: "The value of the 'Access-Control-Allow-Origin' header in the response must not be '*' when the request's credentials mode is 'include'." The server must echo the exact Origin instead of using * and also set Access-Control-Allow-Credentials: true.
How to fix Credentials Not Supported
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Reflect exact origin
Change the backend CORS policy to dynamically read the incoming 'Origin' header, validate it against a whitelist, and return that exact string instead of '*'.
Allow credentials header
Ensure you add the 'Access-Control-Allow-Credentials' header to the backend response.
add_header 'Access-Control-Allow-Credentials' 'true';Remove frontend credentials
If you don't actually need to send cookies (e.g., you are using JWTs in an Authorization header), remove 'credentials: include' or 'withCredentials = true' from your frontend request.
Technical Background
When 'credentials: include' is set on a fetch request (or 'withCredentials' on XHR), the browser attempts to attach ambient credentials—like session cookies, TLS client certificates, or HTTP Basic Auth—to the cross-origin request.
To protect against Cross-Site Request Forgery (CSRF) attacks, the CORS specification mandates that the server must be acutely aware of exactly who is making the authenticated request. The server must explicitly declare the exact origin it trusts.
If the server responds with the wildcard '*', it is essentially saying 'I allow authenticated requests from literally any website on the internet'. The browser interprets this as a dangerous misconfiguration and immediately fails the request to protect the user's session.
Furthermore, even if the server returns the exact specific origin, the browser requires a secondary confirmation: the 'Access-Control-Allow-Credentials: true' header. Without this explicit opt-in, the browser will discard the response.
Common Causes
- The frontend fetch() or XMLHttpRequest is configured with 'credentials: include' (intentionally sending cookies or HTTP Basic Auth).
- The backend server is responding to the request with a lazy 'Access-Control-Allow-Origin: *' wildcard policy.
- The backend server is returning the correct specific origin, but is missing the mandatory 'Access-Control-Allow-Credentials: true' header.
Typical Scenarios
- A frontend application trying to authenticate a user via secure session cookies with an API located on a different subdomain (e.g., app.domain.com talking to api.domain.com).
- An API server configured with a generic 'CORS=*' policy suddenly breaking when developers attempt to introduce session-based authentication.
- A frontend developer setting 'withCredentials = true' globally in Axios, inadvertently breaking requests to public wildcard APIs.
What to Know
To fix this securely, your backend must parse the incoming HTTP 'Origin' header, check if it belongs to an allowed list of trusted domains, and if so, echo that exact origin string back in the 'Access-Control-Allow-Origin' header. You must also append 'Access-Control-Allow-Credentials: true'. Do not use wildcards on authenticated routes.
Frequently Asked Questions
Common questions about CORS Credentials Not Supported error
Using '*' with credentials is a massive security risk. If a server allows credentials (cookies) and also allows any origin ('*'), a malicious website could silently make authenticated requests on behalf of a visiting user. Browsers explicitly forbid this combination to protect against Cross-Site Request Forgery (CSRF).
You must satisfy BOTH requirements. You must have Access-Control-Allow-Credentials: true, AND your Access-Control-Allow-Origin cannot be '*'. It must be the exact string of the frontend domain, like 'https://myfrontend.com'.
If you are using the 'cors' package in Express, simply configure it with an array of allowed origins: `cors({ origin: ['https://site-a.com', 'https://site-b.com'], credentials: true })`. The middleware will handle reflecting the exact origin automatically.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Process Killed — the process was terminated by a SIGKILL signal
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Exit Code 139 — process terminated by segmentation fault (Signal 11 / SIGSEGV)
Input/output error EIO — a read or write operation could not complete