Memory Leak in Express with Basic Auth

A memory leak in an Express application using HTTP Basic Auth can occur when request handling paths retain references to authentication state or parsed credentials on the request or response objects. Unlike token-based flows where short-lived JWTs are often validated and discarded, Basic Auth credentials are typically re-derived on each request from the Authorization header and stored in middleware state for the lifetime of the request. If middleware or route handlers attach parsed user information (e.g., a user object or parsed credentials) to the request object and never clean them up, or if closures capture these references unintentionally, the garbage collector cannot reclaim that memory across requests. This pattern is especially risky under sustained load because retained objects accumulate, increasing heap usage and potentially triggering more frequent garbage collection cycles that degrade performance.

In the context of middleBrick’s security checks, a Memory Leak is one of the 12 parallel scans. The scanner inspects runtime behavior and OpenAPI/Swagger specifications (with full $ref resolution) to identify indicators such as unbounded request caching, missing cleanup of per-request state, or improper handling of authorization data. When Basic Auth is used, the scanner pays particular attention to how credentials are stored and whether parsed authentication details persist beyond the immediate request lifecycle. Although the scanner detects and reports these patterns with severity and remediation guidance, it does not fix or block execution; it provides actionable findings. Real-world attack patterns like inefficient object retention map to broader issues such as OWASP API Top 10’s ‘Improper Resource Management’ considerations, and continuous monitoring in the Pro plan can help detect regressions over time by tracking score changes and related findings.

Example of problematic Express middleware that can contribute to retention when combined with Basic Auth:

const users = new Map();

app.use((req, res, next) => {
  const auth = req.headers.authorization;
  if (auth && auth.startsWith('Basic ')) {
    const base64 = auth.split(' ')[1];
    const decoded = Buffer.from(base64, 'base64').toString('utf-8');
    const [user, pass] = decoded.split(':');
    // Attaching user to request and storing in a global map without cleanup
    req.user = { user, role: 'user' };
    users.set(req.id, req.user);
  }
  next();
});

app.get('/profile', (req, res) => {
  res.json(users.get(req.id));
});

In this snippet, users grows indefinitely because entries are never removed. The combination of Basic Auth’s per-request credential parsing and stateful caching illustrates how memory can accumulate. middleBrick’s scan would flag findings tied to Inventory Management and Unsafe Consumption checks, highlighting improper resource handling and suggesting remediation that avoids persistent storage of per-request data.

To mitigate memory leaks when using HTTP Basic Auth in Express, avoid retaining parsed credentials beyond the request lifecycle and do not store per-request data in global or long-lived structures. Instead, derive the necessary authorization information on demand for each request and keep objects scoped locally. If you need to reference user roles or permissions, fetch them from a lightweight, request-scoped source rather than caching them globally.

Remediation example with proper scoping and no persistent cache:

app.use((req, res, next) => {
  const auth = req.headers.authorization;
  if (auth && auth.startsWith('Basic ')) {
    const base64 = auth.split(' ')[1];
    const decoded = Buffer.from(base64, 'base64').toString('utf-8');
    const [user, pass] = decoded.split(':');
    // Perform validation here (e.g., check a user database)
    // Create a request-scoped user object, do not attach to a global map
    req.user = { user, role: 'user' };
  }
  next();
});

app.get('/profile', (req, res) => {
  if (!req.user) {
    return res.status(401).send('Unauthorized');
  }
  // Use only request-scoped data; no global storage
  res.json({ profileFor: req.user.user });
});

This approach ensures that each request constructs its own authorization context and releases it when the response is sent, allowing the garbage collector to reclaim memory. For applications that require role-based access, validate credentials against a store on each request or use short-lived in-memory caches with eviction policies rather than indefinite retention. The free tier of middleBrick supports up to three scans per month, which can be useful for validating that changes to authentication handling do not introduce new retention issues. For teams needing continuous oversight, the Pro plan provides ongoing monitoring and integrates with CI/CD via the GitHub Action to fail builds if risk scores degrade, while the CLI (middlebrick scan <url>) enables quick local checks and JSON output for scripting.

Additionally, ensure you rotate credentials and use HTTPS to protect Basic Auth credentials in transit, as sending credentials on every request increases exposure if logs or headers are captured. The scanner’s LLM/AI Security checks are not applicable to Basic Auth configurations, but its inventory and data exposure checks can highlight insecure storage or transmission practices. By combining scoped authorization patterns with automated scanning, you reduce the likelihood of memory accumulation and maintain better runtime stability.