Cache Poisoning in Express (Javascript)

Cache poisoning in Express applications using JavaScript occurs when an attacker manipulates cached responses so that subsequent users receive malicious or incorrect data. This typically arises when dynamic routes or query parameters are improperly handled and responses are cached based only on a subset of the request, such as the path without considering query strings or headers. In Express, JavaScript logic that determines cache keys or caching behavior on the server or in a CDN can inadvertently treat similar paths as equivalent, causing a poisoned cache entry to be served to unrelated users.

Consider an Express route that uses query parameters to filter data without validating or normalizing them before caching. If the cache key is derived solely from req.path and ignores req.query, a crafted request like /api/products?category=electronics could be cached and later served to a user requesting /api/products?category=malware. Because the cache treats both as the same key, the second user receives the poisoned response. In JavaScript, this risk is heightened when developers use concatenated strings to form cache keys or when middleware applies caching heuristically without accounting for all request dimensions.

Another common pattern is caching authenticated responses at a shared location, such as a reverse proxy or in-memory store, without incorporating user context into the key. In Express, if a developer caches the rendered output of a user-specific page using only the URL path, one user’s sensitive data could be served to another user. The Express app might use JavaScript to set headers like Cache-Control in a per-route handler, and if those headers do not account for variations such as user identifiers or role-based access, the cache can become a vector for data exposure.

Real-world attack patterns mirror issues documented in the OWASP API Top 10 and have been observed in frameworks when cache invalidation is handled incorrectly. For example, an attacker might probe endpoints that reflect user input in cached responses, attempting to inject script or sensitive information that persists across requests. Because Express is commonly used to serve both API and rendered views, misconfigured caching in JavaScript can affect both JSON APIs and HTML responses, amplifying the impact of cache poisoning.

To mitigate cache poisoning in Express with JavaScript, ensure that cache keys are deterministic, normalized, and include all relevant components of the request that affect the response. This includes the full path, query parameters, selected headers, and, where necessary, user context. Avoid string concatenation to form cache keys; instead, use a structured approach that explicitly defines which fields participate in cache differentiation.

Below are concrete Express code examples that demonstrate secure handling of caching in JavaScript.

const express = require('express');
const crypto = require('crypto');

const app = express();

// Secure cache key generation that includes method, path, and sorted query keys
function buildCacheKey(req) {
  const queryKeys = Object.keys(req.query).sort();
  const queryString = queryKeys.map(k => `${k}=${req.query[k]}`).join('&');
  const normalized = queryString ? `${req.method} ${req.path}?${queryString}` : `${req.method} ${req.path}`;
  // Optionally include a header like Accept if responses vary by content negotiation
  return crypto.createHash('sha256').update(normalized).digest('hex');
}

app.get('/api/products', (req, res) => {
  const key = buildCacheKey(req);
  // pseudo-cache lookup using key
  const cached = cache.get(key);
  if (cached) {
    return res.set(cached.headers).send(cached.body);
  }

  // Simulated data retrieval and response
  const data = getDataFilteredByQuery(req.query);
  const headers = { 'Cache-Control': 'public, max-age=300' };
  cache.set(key, { headers, body: data });
  res.set(headers).send(data);
});

function getDataFilteredByQuery(query) {
  // Validate and normalize query inputs before using them
  const category = typeof query.category === 'string' ? query.category.trim().toLowerCase() : null;
  const limit = Number.isInteger(query.limit) ? query.limit : 10;
  // ... fetch and filter data safely
  return { category, limit };
}

The example above demonstrates how to construct a cache key that incorporates HTTP method, path, and sorted query parameters. By hashing the normalized representation, you avoid key collisions and ensure that distinct requests are cached separately. This prevents an attacker from forcing a specific query to overwrite a cache entry that is later served to users with different query values.

Additionally, always validate and normalize input used in response generation. In the helper getDataFilteredByQuery, query values are explicitly typed and sanitized before being used. This reduces the risk that malicious input is interpreted differently when the same cache key is reused. For responses that vary by user roles or headers, include those dimensions in the cache key rather than relying on path alone.

When using middleware to set cache headers, ensure the logic accounts for context. For example, avoid setting broad Cache-Control rules for endpoints that include user-specific data. Instead, conditionally apply no-cache or private caching when user context is present. The Express application should explicitly define which responses are safe to share and which must remain isolated per request or per user.