Axios Misconfiguration Security Risks Explained

Axios is one of the most widely used promise-based HTTP clients for JavaScript and Node.js applications. While it offers a simple API for making network requests, improper configurations can introduce severe security vulnerabilities into both client-side and server-side applications. This guide examines the primary security risks associated with misconfigured Axios instances, including Server-Side Request Forgery (SSRF), credential leakage, Denial of Service (DoS), and disabled transport security.

1. Server-Side Request Forgery (SSRF)

When Axios is used in Node.js backends to fetch resources based on user-supplied inputs, failing to validate or sanitize URLs can lead to Server-Side Request Forgery.

If an application directly passes raw user input into axios.get(userUrl) or dynamically constructs a baseURL, an attacker can point requests toward internal network resources (such as http://localhost, cloud metadata endpoints like http://169.254.169.254, or internal databases).

Prevention:

• Maintain an allowlist of permitted hostnames and protocols.
• Prevent requests to private IP ranges (e.g., 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16).
• Disallow protocol switching (e.g., restricting inputs strictly to https:).

2. Unintended Credential Leakage via Redirects

Axios follows HTTP redirects by default. In complex configurations, custom request headers containing sensitive information—such as Authorization: Bearer <token> or custom API keys—might inadvertently be forwarded to an untrusted third-party server if a request is redirected.

While modern versions of Axios strip sensitive headers across cross-origin redirects by default, custom interceptors or custom HTTP agents can override this safe behavior.

Prevention:

• Limit the maximum number of allowed redirects using maxRedirects: 0 or a strictly controlled integer.
• Review request interceptors to ensure they do not re-attach sensitive authentication headers to untrusted destination URLs.

3. Denial of Service (DoS) via Unset Timeouts

By default, Axios does not configure a request timeout (timeout: 0). When Axios is running in a server-side environment, a hanging or slow external server can cause requests to remain open indefinitely.

If multiple requests hang, connection pools and system memory become exhausted, resulting in a Denial of Service (DoS) that prevents the application from handling legitimate traffic.

Prevention:

• Always define an explicit timeout on global instances or per-request configs:

const apiClient = axios.create({
  baseURL: 'https://api.example.com',
  timeout: 5000 // 5 seconds
});

4. Insecure TLS/SSL Verification

Developers often disable TLS certificate verification during local debugging by passing a custom httpsAgent with rejectUnauthorized: false. If this configuration reaches staging or production environments, it exposes network communication to Man-in-the-Middle (MitM) attacks.

Prevention:

• Never deploy rejectUnauthorized: false to production.
• Use valid certificates or inject custom Certificate Authority (CA) bundles into the agent using the ca parameter rather than disabling verification entirely.

5. Misconfigured CSRF/XSRF Protection

Axios provides built-in support for Cross-Site Request Forgery (CSRF) protection by automatically reading a token from a cookie (default: XSRF-TOKEN) and setting it as an HTTP header (default: X-XSRF-TOKEN).

Security issues arise when:

• Developers customize xsrfCookieName or xsrfHeaderName improperly, leading the client to skip sending necessary tokens.
• Axios is allowed to send credentials and XSRF headers automatically to untrusted third-party endpoints, potentially leaking protection tokens to malicious domains.

Prevention:

• Ensure xsrfCookieName matches the exact cookie set by the backend server.
• Avoid exposing CSRF tokens on requests directed outside the application's primary domain.

6. Dangerous Response Deserialization and Prototype Pollution

By default, Axios automatically parses JSON responses. If an application interacts with an untrusted external API, maliciously crafted JSON payloads containing keys such as __proto__ or constructor can trigger prototype pollution vulnerabilities when merged unsafely into application state objects.

Prevention:

• Validate and sanitize incoming response data using schema validation libraries (such as Zod or Joi) before merging it with application objects.
• Override transformResponse if custom deserialization or non-standard payloads must be safely parsed.