Back to results for “Caching”
Node.js › Caching

What is the risk of caching sensitive or user-specific data with a shared cache key, and how do you avoid it?

Intermediate

Answer

If a cache key doesn't incorporate the identity of the requesting user (or tenant, or permission context), one user's request could be served another user's cached, personalized data -- a serious privacy bug. The fix is ensuring cache keys always include every dimension the response varies by (user ID, locale, permission level), the same principle behind the HTTP 'Vary' header.
// Bug: cache key doesn't include the user
const cacheKey = 'dashboard-data';

// Fixed: cache key scoped to the specific user
const cacheKey = `dashboard-data:${userId}`;
Real-world example A security audit discovers a dashboard-caching layer used a single shared cache key regardless of the logged-in user, meaning the first user to load the dashboard after expiration had their personalized data served to every subsequent user until the entry expired.

Common follow-ups: What other dimensions besides user ID commonly need to be included in a cache key (locale, currency, permission role)?;How does the HTTP 'Vary' header address this same class of problem for CDN and browser caching?