Cache Poisoning in Koa (Javascript)

Cache poisoning in Koa with JavaScript arises when an attacker can influence cached responses through crafted request inputs. Because Koa is a lightweight Node.js framework, developers commonly use HTTP caching headers (e.g., Cache-Control, ETag) or integrate reverse caches like Varnish or CDNs. If user-controlled data (such as query parameters, headers, or cookies) affects the response but is not properly validated or segregated, cached entries can be polluted and served to other users.

For example, reflecting untrusted input into cached HTML fragments or JSON payloads can lead to authenticated users seeing others’ data or executing unintended logic. Consider a Koa route that appends a custom header value into the response body without sanitization:

const Koa = require('koa');
const app = new Koa();

app.use(async (ctx) => {
  const user = ctx.query.user || 'guest';
  ctx.set('Cache-Control', 'public, max-age=30');
  ctx.body = { message: `Hello, ${user}` };
});

app.listen(3000);

If the user query parameter is reflected into a shared cache key without normalization, an attacker could request ?user=evil and cause subsequent requests for the default response to return the poisoned payload. This is especially risky when caching is applied at the infrastructure layer and the application does not differentiate responses per user context. Attack chains may include session fixation or information disclosure when cached responses contain sensitive headers or cookies.

The 12 security checks in middleBrick run in parallel and include Data Exposure, Input Validation, and Authentication. When scanning a Koa endpoint, the scanner evaluates whether response variations based on inputs are safely cached, whether cache headers are applied per user context, and whether sensitive data could be stored or returned inadvertently. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and relevant compliance controls.

Using middleBrick’s free tier, you can quickly test unauthenticated attack surfaces to detect basic cache poisoning indicators. For continuous monitoring and deeper analysis across many endpoints, the Pro plan provides configurable schedules, Slack/Teams alerts, and compliance reports. The CLI tool enables automated scans in scripts, while the GitHub Action can gate merges if risk scores exceed your threshold.

To remediate cache poisoning in Koa with JavaScript, ensure cached responses are keyed on a normalized request context and avoid reflecting untrusted input into cacheable payloads. Use explicit cache keys that exclude or sanitize user-controlled values, and set appropriate Cache-Control directives to prevent caching of sensitive or user-specific data.

1) Do not reflect untrusted input directly into cached responses. Sanitize and validate inputs, and avoid using them in cache keys unless necessary:

const Koa = require('koa');
const escape = require('escape-html');
const app = new Koa();

app.use(async (ctx) => {
  const rawUser = ctx.query.user;
  const safeUser = typeof rawUser === 'string' ? escape(rawUser.trim()) : 'guest';
  ctx.set('Cache-Control', 'no-store'); // Prevent caching of user-specific content
  ctx.body = { message: `Hello, ${safeUser}` };
});

app.listen(3000);

2) If caching is required, scope cache keys to include only safe, non-user-specific components and enforce strict header handling. Do not forward sensitive headers into cached responses:

const Koa = require('koa');
const crypto = require('crypto');
const app = new Koa();

function cacheKey(ctx) {
  // Build a key from method and path only; exclude query parameters that may contain PII
  return `${ctx.method}:${ctx.path}`;
}

app.use(async (ctx, next) => {
  const key = cacheKey(ctx);
  // pseudo cache lookup/store using key
  const cached = getFromCache(key);
  if (cached) {
    ctx.body = cached.body;
    ctx.set('X-Cache', 'HIT');
    return;
  }
  await next();
  // Only cache safe, non-personalized responses
  if (ctx.status === 200 && !ctx.request.query.user) {
    setInCache(key, { body: ctx.body, headers: pickSafeHeaders(ctx.response) });
    ctx.set('X-Cache', 'MISS');
  }
});

// Helper to pick non-sensitive headers
function pickSafeHeaders(res) {
  const safe = {};
  const allowed = ['content-type', 'content-length'];
  res.headers.forEach((value, key) => {
    if (allowed.includes(key.toLowerCase())) safe[key] = value;
  });
  return safe;
}

function getFromCache(key) { /* implement cache store */ return null; }
function setInCache(key, val) { /* implement cache store */ }

app.listen(3000);

3) Avoid caching responses that contain authentication or per-user data. Explicitly set Cache-Control to no-store for endpoints where user context affects content:

const Koa = require('koa');
const app = new Koa();

app.use(async (ctx, next) => {
  await next();
  if (ctx.path.startsWith('/me') || ctx.session) {
    ctx.set('Cache-Control', 'no-store, no-cache, must-revalidate, proxy-revalidate');
  }
});

app.use(async (ctx) =>
  ctx.body = { profile: 'safe for public caching' }
);

app.listen(3000);

These JavaScript-focused practices reduce the risk of cache poisoning by controlling what varies in cache keys, preventing reflection of untrusted data, and disabling caching where user context is involved. middleBrick can identify missing cache controls and reflected inputs during scans, providing prioritized findings and remediation steps.