Cache keys include the tenant identifier

CWE-524 (Use of Cache Containing Sensitive Information) combined with OWASP A01 describes exactly this failure: a cache key like dashboard-stats that is populated by Tenant A's first request and then returned unchanged to Tenant B. Unlike database-layer isolation gaps, cache leaks are silent — no error is raised, the data looks valid, and the victim tenant never knows they received another org's numbers. The window for cross-tenant exposure is bounded only by the cache TTL, which is often measured in minutes or hours.

Prefix every cache key for tenant-specific data with the tenant identifier. Apply this to Redis, Upstash, Next.js unstable_cache, and React Query/SWR cache keys:

// Instead of:
const cacheKey = `dashboard-stats`

// Do this:
const cacheKey = `tenant:${session.user.organizationId}:dashboard-stats`

// For Next.js unstable_cache:
const getData = unstable_cache(
  async () => fetchDashboardStats(orgId),
  [`org-${orgId}-dashboard-stats`],
  { tags: [`org-${orgId}`, 'dashboard-stats'] }
)

// Invalidate with tenant scope:
await revalidateTag(`org-${orgId}`)

Audit cache invalidation paths too — a key-scoped write is safe, but a global flushAll in a multi-tenant cache is a denial-of-service risk for other tenants.