Cache invalidation
Authorisation must survive a cache hit
Reusing data must not reuse another caller's authority. Review access checks before and after the point where a cached value enters the response.
In this article
Separate data reuse from permission reuse
A service loads a private report after checking a manager's access and caches the rendered response by report identifier. A second employee requests the same identifier and receives the cached response before the permission check runs.
The first database read was properly authorised. The cache introduced a second path that skipped the original control.
Draw the request path for both hits and misses. The access decision should protect every path that returns restricted information, including shortcuts added for performance.
Decide what can be shared safely
A raw record may be reusable within a tenant if each request still checks whether the caller may access it. A rendered response containing role-specific fields requires additional scope or separate rendering.
Do not assume a user identifier in the key solves revocation. A user can lose a role while an earlier response remains cached. The application must honour the chosen revocation policy when deciding whether to reuse that response.
Permission caches deserve their own freshness analysis. A long duration chosen to reduce identity-provider calls can preserve rights longer than the business intends.
Inspect every storage layer
Review HTTP response policy for private pages and API responses. In HTTP caching, private limits shared-cache storage, while no-store addresses storage more broadly. No-cache allows storage but requires validation before reuse under the standard. These names should not be treated as interchangeable.
Application memory, client query stores and service workers need separate review. Response headers do not automatically erase values an application has copied into its own state.
Test account switching and logout on a shared device. Check the rendered screen, browser history behaviour and subsequent requests. Avoid promising that one header can retract content already displayed or copied.
Use two identities in the test
Create one caller with access and one without. Populate the cache with the authorised caller, then request the same resource as the other caller. Repeat after revoking the first caller's access.
Inspect response bodies as well as status codes. An error shell that embeds private data in hydration state is still a disclosure.
Keep cache administration restricted because operators may be able to inspect stored payloads directly. The final review should cover who can read the value through the application and who can read the cache itself.
Primary sources
OWASP: authorisation guidanceHTTP caching standardReferences checked 11 September 2026.