Axios Credentials and Wildcard CORS Security Risks

This article provides an overview of the critical security risks associated with enabling credentials on cross-origin requests using the Axios HTTP client when interacting with servers utilizing wildcard or permissive CORS policies. It covers the browser-level protections in place, the hazards of server-side origin reflection misconfigurations, vulnerabilities such as unauthorized data exposure and Cross-Site Request Forgery (CSRF), and best practices for secure cross-origin communication.

Understanding Credentials and CORS in Axios

When making HTTP requests using Axios, the withCredentials: true configuration flag instructs the browser to include ambient credentials—such as cookies, HTTP authentication headers, and TLS client certificates—in cross-origin requests.

By default, the Cross-Origin Resource Sharing (CORS) standard strictly regulates credentialed requests. According to the W3C and WHATWG specifications, a browser will reject any credentialed request where the server responds with a wildcard origin header (Access-Control-Allow-Origin: *) paired with Access-Control-Allow-Credentials: true.

The Fallacy of Client-Side Protection

While modern web browsers enforce the rule that blocks JavaScript from reading a response when Access-Control-Allow-Origin: * is paired with credentials, relying solely on this behavior introduces major security issues:

  1. State-Changing Execution (One-Way Execution): Even if the browser prevents Axios from reading the response data, the request itself may still reach the server and execute. If the request performs a state-changing action (such as modifying an account setting or transferring funds), the operation succeeds on the backend despite the frontend receiving a CORS error.
  2. Simple vs. Preflighted Requests: Certain "simple" requests (e.g., standard GET or POST requests with basic Content-Type headers) do not trigger a preflight OPTIONS request. The browser dispatches the credentialed payload immediately, executing backend logic before evaluating the CORS response headers.

The Risk of Server-Side Dynamic Reflection

When developers encounter browser CORS errors triggered by Axios's withCredentials: true against a wildcard endpoint, a common anti-pattern is to configure the backend to dynamically reflect the request's Origin header in the Access-Control-Allow-Origin response header.

Dynamically mirroring the incoming Origin while setting Access-Control-Allow-Credentials: true effectively turns the endpoint into an authenticated wildcard. The security implications of this misconfiguration include:

  • Cross-Origin Data Leakage: Any malicious website visited by an authenticated user can make an Axios-based request to the vulnerable API, read sensitive personal data, and exfiltrate the response.
  • Bypassing Network Boundaries: Internal APIs or intranet services exposed with dynamic reflection allow external malicious sites to pivot through the victim's browser and extract confidential internal data.

Impact on CSRF Defenses

Enabling credentials on poorly secured cross-origin endpoints weakens ambient authentication mechanisms. If an application relies solely on cookies for session identification without explicit anti-CSRF defenses (such as anti-CSRF tokens or strict SameSite configurations), malicious third-party origins can forge authenticated requests using the user's active session.

Mitigation and Best Practices

To avoid vulnerabilities when using withCredentials: true in Axios:

  • Enforce Strict Origin Validation: On the server side, validate the Origin header against an explicit, immutable allowlist of trusted domains before setting Access-Control-Allow-Credentials: true. Never reflect arbitrary incoming origins.
  • Implement Modern Cookie Attributes: Mark session cookies with SameSite=Lax or SameSite=Strict and the Secure flag to restrict when browsers attach cookies to cross-site requests.
  • Use Explicit Authorization Headers: When possible, pass authentication tokens explicitly via custom headers (e.g., Authorization: Bearer <token>) rather than relying on automatic ambient cookie transmission.
  • Separate Public and Authenticated Endpoints: Never configure authenticated endpoints to use wildcard CORS rules. Public data should remain unauthenticated and separate from private APIs.