Memory Leak in Express with Api Keys

A memory leak in an Express application that manages API keys can arise when keys and associated request contexts are retained unintentionally. For example, storing per-request API key metadata in a global map without cleanup causes the heap to grow as requests arrive. This pattern becomes problematic when keys are attached to long-lived objects or closures that remain reachable, preventing garbage collection. In a typical Express route, creating a new object for each request and storing it in a module-level cache without eviction leads to retained references:

const keyCache = new Map();

app.use((req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (apiKey) {
    // Risk: unbounded growth if never cleaned up
    keyCache.set(apiKey, { timestamp: Date.now(), req });
  }
  next();
});

The req reference in the cached value keeps the entire request object (including parsed body, headers, and downstream closures) alive. Over time, this increases memory footprint and may degrade performance. In the context of middleBrick’s 12 security checks, this behavior can be flagged under Property Authorization and Unsafe Consumption, as unbounded caching of sensitive key material represents an insecure consumption pattern that may contribute to denial-of-service via resource exhaustion. The scan does not fix the leak but highlights the retention as a finding with remediation guidance.

Additionally, if API keys are logged or echoed in responses during debugging, sensitive material may remain in memory longer than necessary, increasing exposure risk. MiddleBrick’s Data Exposure check would surface such retention alongside findings from its LLM/AI Security suite when applicable, ensuring that key handling is reviewed for both runtime and model interaction risks. Because middleBrick operates as a black-box scanner, it identifies the symptom—prolonged memory retention—without needing internal architecture details, delivering a reproducible, 5–15 second assessment.

To remediate memory leaks related to API keys in Express, avoid storing request-scensitive data in long-lived caches without size limits and cleanup strategies. Use bounded data structures and ensure cached entries are released when no longer needed. Below are two concrete patterns with syntactically correct Express examples.

1. Bounded cache with TTL and cleanup

Replace unbounded maps with a fixed-size cache that evicts old entries. A simple approach uses a JavaScript object with timestamp checks and periodic pruning:

const keyStore = {};
const MAX_ENTRIES = 1000;
const TTL_MS = 300000; // 5 minutes

function cleanupKeys() {
  const now = Date.now();
  for (const [key, entry] of Object.entries(keyStore)) {
    if (now - entry.timestamp > TTL_MS) {
      delete keyStore[key];
    }
  }
}

// Run cleanup periodically
setInterval(cleanupKeys, 60000);

app.use((req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (apiKey) {
    if (Object.keys(keyStore).length >= MAX_ENTRIES) {
      cleanupKeys();
    }
    keyStore[apiKey] = { timestamp: Date.now() };
  }
  next();
});

This reduces the risk of unbounded memory growth and aligns with secure handling of API keys by limiting retention. MiddleBrick’s Property Authorization check would validate that such controls are in place, and its continuous monitoring (available in the Pro plan) can alert you if deviations are detected in subsequent scans.

2. Stateless key validation without caching

For many scenarios, you can avoid caching altogether by validating keys against a fast data source on each request, ensuring no unnecessary references are retained:

app.use((req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  if (apiKey) {
    // Validate key synchronously or via a lightweight call
    if (!isValidKey(apiKey)) {
      return res.status(401).send('Invalid API key');
    }
  }
  next();
});

function isValidKey(key) {
  // Replace with actual validation logic, e.g., database or Redis lookup
  return key === 'expected-secret-key';
}

This pattern eliminates retention risks entirely and is straightforward to integrate into CI/CD pipelines using the middleBrick GitHub Action to fail builds if insecure key handling patterns are detected. The CLI tool (middlebrick scan <url>) can be used locally to verify fixes, and the Web Dashboard helps track improvements over time.