Cache deception and cache poisoning
Review cache keys, response eligibility, and invalidation so a response remains correct for the requester and representation that produced it.
This is the complete downloadable file. Open plain text ↗
---
name: cache
description: "Review cache keys, response eligibility, and invalidation so a response remains correct for the requester and representation that produced it."
---
# Cache deception and cache poisoning
Review cache keys, response eligibility, and invalidation so a response remains correct for the requester and representation that produced it.
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
## Bring to the review
- Cache configuration
- Response headers and variation rules
- Authorization and tenant model
## Review guide
### 1. Classify response data
Separate public, tenant-scoped, user-scoped, and diagnostic responses before deciding what may be stored.
### 2. Trace the key
Document every request property that changes representation, permission, locale, or tenant and confirm it participates in cache selection.
### 3. Review invalidation
Check privilege changes, logout, mutations, and deployment events for a safe freshness or purge strategy.
### 4. Bound capacity
Ensure key cardinality and cache partitioning preserve availability without collapsing distinct security contexts.
## What to produce
- Cache eligibility matrix
- Key and variation inventory
- Invalidation policy
## Common mistakes
- Caching personalized representations as public
- Forgetting authorization-affecting variation
- Assuming freshness implies authorization
## Reading and source context
### Resources
- [Web cache key precision and capacity isolation](https://vulns.co/research/resources/arxiv-2026-cache-key-precision-and-capacity/)
- [Nuxt: rendered-data caches must preserve request authorization](https://vulns.co/research/resources/nuxt-2026-rendered-payload-cache-authorization/)
- [Next.js: response metadata must preserve representation boundaries](https://vulns.co/research/resources/nextjs-2026-response-metadata-representation-boundary/)
### Diagrams
- [Combined views preserve every source's access boundary](https://vulns.co/research/diagrams/combined-view-source-authorization/)
### Reports
- [GitHub comparison output lacked source-repository authorization](https://vulns.co/research/reports/github-cross-repository-comparison-authorization-2025/)
## Provenance
Editorial guide by vulns.co / GK Data. Updated 2026-10-11.
Library snapshot: 2026-10-04; commit d5550c7891119cf1379e235721541c947850a3b3.
The guide is an editorial synthesis. Linked records preserve their own sources and review dates.
Reader: https://vulns.co/skills/cache/
The review
What to look for
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
Classify response data
Separate public, tenant-scoped, user-scoped, and diagnostic responses before deciding what may be stored.
Trace the key
Document every request property that changes representation, permission, locale, or tenant and confirm it participates in cache selection.
Review invalidation
Check privilege changes, logout, mutations, and deployment events for a safe freshness or purge strategy.
Bound capacity
Ensure key cardinality and cache partitioning preserve availability without collapsing distinct security contexts.
What to produce
- Cache eligibility matrix
- Key and variation inventory
- Invalidation policy
Common mistakes
- Caching personalized representations as public
- Forgetting authorization-affecting variation
- Assuming freshness implies authorization
Continue the study
Reading & source context
Editorial notes above connect these references. Open each record for its original source and review date.
Visual models
Connected disclosures
From the field toolkit
Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.