How to Securely Use Access-Control-Allow-Credentials in CORS

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• The header only accepts the literal value true; omit it to disallow credentials.
• Access-Control-Allow-Origin must echo the request origin when credentials are allowed; * is forbidden.
• Enable the header only for endpoints that need user - specific data and always validate the Origin header.
• Use fetch(..., { credentials: "include" }) or XMLHttpRequest.withCredentials = true on the client to trigger credentialed requests.

What does Access-Control-Allow-Credentials do?

Access-Control-Allow-Credentials tells the browser whether it may expose a cross - origin response to JavaScript when the request includes credentials such as cookies or HTTP authentication. If the header is present with the value true, the browser delivers the response; otherwise the request fails with a network error.

What is the only valid value for the header?

The specification defines a single case - sensitive token true. The header must be omitted when credentials are not allowed; there is no false value.

Access-Control-Allow-Credentials: true

When is the header evaluated?

• For a pre - flight request, the header in the pre - flight response indicates that the subsequent actual request may include credentials.
• For a simple (non - pre - flight) request, the header must appear in the actual response and equal true; otherwise the browser treats the response as a network error.

How must Access-Control-Allow-Origin be set when credentials are allowed?

When Access-Control-Allow-Credentials: true is used, Access-Control-Allow-Origin cannot be the wildcard *. The server must echo the exact origin from the request, for example:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

How does a client request credentials?

• fetch('https://api.example.com/data', { credentials: "include" })
• const xhr = new XMLHttpRequest(); xhr.withCredentials = true;
• const es = new EventSource(url); es.withCredentials = true;

Why is the header a security risk if misused?

Browsers block credentials on cross - origin requests by default because sending cookies or auth tokens can enable CSRF attacks. Enabling credentials without strict origin checks lets any site read user - specific data from your API.

Concrete steps to configure Access-Control-Allow-Credentials safely

1. Identify endpoints that need user - specific data - only APIs that return personalized information should allow credentials.
2. Validate the Origin header - compare the incoming Origin against an allow - list before echoing it back.
3. Set the header conditionally - only add Access-Control-Allow-Credentials: true when the origin is approved.
4. Never use the wildcard - always echo the request origin; do not fall back to *.
5. Test with both pre - flight and simple requests - ensure browsers receive the header in the correct response type.
6. Monitor logs for unexpected origins - flag any request that tries to use credentials from an unknown origin.

// Example Node/Express middleware
app.use((req, res, next) => {
 const allowedOrigins = ['https://app.example.com', 'https://admin.example.com'];
 const origin = req.headers.origin;
 if (allowedOrigins.includes(origin)) {
 res.setHeader('Access-Control-Allow-Origin', origin);
 res.setHeader('Access-Control-Allow-Credentials', 'true');
 }
 next();
});

How does this relate to other CORS headers?

Access-Control-Allow-Credentials works together with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. Misconfiguring any of these can break the security model, but the credential header is the only one that directly controls whether browsers expose sensitive cookies or auth tokens.

When should you disable the header?

• For public resources that do not depend on user identity.
• When the API is intended for use by third - party websites that should not have access to user sessions.
• If you cannot reliably validate the Origin header (e.g., due to a proxy stripping it).

Summary

Access-Control-Allow-Credentials is a powerful but narrow tool. Use it only when a response truly requires user credentials, always echo a validated origin, and never combine it with a wildcard origin. Following these concrete steps prevents accidental CSRF exposure while still enabling legitimate cross - origin interactions.