Cache Poisoning in Strapi with Firestore

Cache poisoning in the context of Strapi with Firestore occurs when an attacker manipulates cached responses so that subsequent requests receive tainted data. Strapi, as a headless CMS, often uses caching to reduce repeated reads from the underlying database, in this case Firestore. If cache keys are derived from unvalidated or attacker-controlled inputs, an adversary can cause the application to store and later serve malicious content to other users or even to the same user in a different context.

For example, consider a Strapi content type that exposes a public API endpoint to list articles. The endpoint might accept query parameters such as locale or fields. If these parameters are directly used to construct a Firestore query and the resulting response is cached without normalizing or validating the parameters, two distinct requests with different locales could share the same cache key. An attacker could request a locale that triggers injection of unexpected script or data, and the poisoned cache entry would serve that content to users requesting a benign locale.

Firestore-specific aspects come into play because Firestore queries are structured and typically include filters on document paths or fields. Strapi may construct queries using concatenated strings or objects derived from request inputs. If these inputs are not strictly validated, an attacker might influence which documents are retrieved or even force the query to return documents that should be restricted. When such a query result is cached, the tainted data persists across requests. Additionally, because Firestore responses can include references or metadata, improperly sanitized data stored in cache may expose sensitive fields or enable client-side code execution when the cached JSON is rendered in a vulnerable frontend.

The risk is compounded when Strapi is configured to serve data to unauthenticated endpoints, as the attack surface expands. An unauthenticated LLM endpoint, if inadvertently exposed, could be probed to understand data shapes, which may assist in refining cache poisoning strategies. middleBrick scans detect unauthenticated LLM endpoints and identify input validation weaknesses that can contribute to cache poisoning, providing prioritized findings and remediation guidance to harden the API surface.

To mitigate cache poisoning in Strapi with Firestore, focus on strict input validation, deterministic cache keys, and safe handling of query parameters. Below are concrete patterns and code examples.

• Validate and sanitize all query parameters. Do not directly pass request query parameters into Firestore queries. Instead, define an allowlist of permitted fields and locales.

const allowedLocales = ['en', 'es', 'fr'];
const allowedFields = ['title', 'slug', 'content'];

async function getArticles(ctx) {
  const { locale = 'en', fields } = ctx.query;
  if (!allowedLocales.includes(locale)) {
    ctx.throw(400, 'Invalid locale');
  }
  const selectedFields = Array.isArray(fields)
    ? fields.filter(f => allowedFields.includes(f))
    : (allowedFields.includes(fields) ? [fields] : ['title', 'slug']);

  const snapshot = await strapi.db.connection.collection('articles')
    .where('locale', '==', locale)
    .select(...selectedFields)
    .get();

  const articles = snapshot.docs.map(doc => doc.data());
  ctx.body = articles;
}

• Normalize cache keys. Derive cache keys from validated inputs only, and avoid including raw query strings.

const crypto = require('crypto');

function buildCacheKey(locale, fields) {
  const normalizedFields = Array.isArray(fields) ? fields.sort().join(',') : (fields || 'title,slug');
  return `articles:locale=${locale}:fields=${crypto.createHash('sha256').update(normalizedFields).digest('hex').slice(0, 16)}`;
}

// Example usage within Strapi controller
const cacheKey = buildCacheKey(locale, selectedFields);
const cached = await cache.get(cacheKey);
if (cached) {
  ctx.body = JSON.parse(cached);
  return;
}
// ... fetch from Firestore, then
await cache.set(cacheKey, JSON.stringify(articles), { ttl: 300 });

• Sanitize Firestore document data before caching. Remove or encode fields that should not be cached, such as internal metadata or sensitive references.

function sanitizeForCache(doc) {
  const { __v, _private, ...publicData } = doc;
  if (publicData.content) {
    publicData.content = escapeHtml(publicData.content);
  }
  return publicData;
}

function escapeHtml(str) {
  return str.replace(/[&<>"']/g, (m) => ({'&':'&','<':'<','>':'>','"':'"',"'":'''}[m]));
}

By combining these practices—validated inputs, deterministic cache keys, and data sanitization—you reduce the risk of cache poisoning in Strapi applications that rely on Firestore as the backend. middleBrick’s checks for input validation and data exposure help surface misconfigurations that could otherwise lead to poisoned caches, and its Pro plan provides continuous monitoring to detect regressions as APIs evolve.