Ssrf in Express with Basic Auth

Server-Side Request Forgery (SSRF) in an Express application that uses HTTP Basic Authentication can amplify risk by exposing internal endpoints that are otherwise protected behind authentication. SSRF occurs when an attacker can coerce the server into making arbitrary outbound HTTP requests, often to internal services that do not expect external traffic. In Express, this commonly arises when user-controlled URLs are passed to HTTP clients without strict validation or network controls.

When Basic Auth is used, credentials are typically stored in server-side session state or passed explicitly to downstream HTTP calls. If an SSRF vector exists, an attacker can bypass the intended access controls by forcing the server to relay requests to internal admin panels, metadata services (e.g., 169.254.169.254 on cloud environments), or other internal APIs. Because the outbound request may reuse authentication headers or a static credential store, the malicious traffic can appear as legitimate authorized requests from the server itself. This can lead to data exposure from internal services, unauthorized configuration reads, or even lateral movement within a private network.

An example scenario: an Express route accepts a URL query parameter and fetches that URL using node-fetch or axios, including a static Basic Auth header derived from a configuration value. An attacker could supply a URL pointing to the local metadata service, and the server’s outbound request would carry the privileged credentials, effectively bypassing any network-level isolation. Because the scan testing methodology used by middleBrick evaluates unauthenticated attack surfaces, such SSRF paths are surfaced as high-severity findings when internal endpoints are reachable from the server environment.

Middleware and proxy setups can further obscure the risk. For instance, an Express app might sit behind a reverse proxy that terminates TLS and adds authorization headers. If the application code does not validate the target host and the proxy configuration is permissive, SSRF can be chained to reach internal destinations that the proxy exposes only to the application layer. The interplay between authentication mechanisms and SSRF increases the impact, since the server may act with elevated privileges that an external attacker would not possess.

Remediation focuses on input validation, network controls, and safe handling of credentials. Avoid using user-controlled data as the sole source for outbound request targets, and do not embed static Basic Auth credentials in code that may be influenced by SSRF paths. Below are concrete, secure patterns for Express.

1. Validate and restrict target hosts

Use an allowlist of permitted hosts and reject URLs pointing to private IP ranges, localhost, or cloud metadata endpoints. Reject URLs with no hostname or with unexpected ports.

const allowedHosts = new Set(['api.example.com', 'data.example.com']);

function isValidTarget(url) {
  try {
    const parsed = new URL(url);
    if (!parsed.hostname) return false;
    if (parsed.hostname === 'localhost') return false;
    // Reject private IPs
    const ip = parsed.hostname;
    const privatePrefixes = ['127.', '10.', '192.168.', '172.16.', '172.17.', '172.18.', '172.19.', '172.20.', '172.21.', '172.22.', '172.23.', '172.24.', '172.25.', '172.26.', '172.27.', '172.28.', '172.29.', '172.30.', '172.31.'];
    if (privatePrefixes.some(p => ip.startsWith(p))) return false;
    if (!allowedHosts.has(parsed.hostname)) return false;
    return true;
  } catch (err) {
    return false;
  }
}

app.get('/fetch', (req, res) => {
  const target = req.query.url;
  if (!isValidTarget(target)) {
    return res.status(400).send('Invalid target');
  }
  // proceed safely
});

2. Use a per-request credential strategy instead of static Basic Auth

Do not reuse a single Basic Auth credential for all outbound requests. If you must use Basic Auth, derive it per request from a secret not directly exposed to SSRF manipulation, and avoid passing user input into the authorization header construction.

const fetch = require('node-fetch');
const authUser = process.env.AUTH_USER;
const authPass = process.env.AUTH_PASS;

app.get('/fetch-safe', (req, res) => {
  const target = req.query.url;
  if (!isValidTarget(target)) {
    return res.status(400).send('Invalid target');
  }
  const creds = Buffer.from(authUser + ':' + authPass).toString('base64');
  fetch(target, {
    headers: { Authorization: 'Basic ' + creds }
  })
    .then(response => response.text())
    .then(text => res.send(text))
    .catch(err => res.status(500).send('Error'));
});

3. Enforce network-level controls

Ensure the runtime environment blocks outbound traffic to private IP ranges and metadata endpoints at the platform or firewall level. This complements application-level validation and reduces the impact of potential SSRF bugs. For example, in container environments, use network policies to deny egress to 169.254.169.254 and other internal services unless explicitly required.

By combining strict host allowlists, secure credential handling, and network segmentation, you mitigate SSRF risks while still using Basic Auth where necessary. These practices align with the findings and remediation guidance provided by security scanning tools that map to frameworks such as OWASP API Top 10 and can be integrated into your workflow using the middleBrick CLI to scan from terminal with middlebrick scan <url>, or added as API security checks to your CI/CD pipeline via the GitHub Action.