Cache

What a cache is and why it exists

A cache is not the source of truth, it is a performance layer. It stores copies of data, objects, or responses close to the code or user that needs them, so repeated reads are faster and upstream systems do less work. That speedup is the core benefit, but it only works because the cached copy can be served before a fresh lookup is required.

The trade-off is that a cache can be right enough for speed but wrong for the latest state. Cache design therefore always involves a freshness policy, whether that is a time-to-live, explicit invalidation, eviction under pressure, or a rule that tells the system when to revalidate a copy before using it again.

Where caches sit in a system

Caches can appear at several layers, and the security and correctness implications change with placement. An in-memory application cache may reduce database load, while a browser cache may store assets or responses for a user session. A shared reverse proxy or application gateway cache can serve many users from the same stored response, which makes configuration and keying especially important.

Because caches sit between the consumer and the original data source, they can change what gets observed, logged, and controlled. A cache hit can hide load on the backing system, while a cache miss can reintroduce latency and dependency on the origin. In distributed systems, those hidden dependencies matter because the cache becomes part of availability and failure behaviour, not just a speed optimisation.

Cache invalidation, expiry, and consistency

Cache invalidation is the hard part because it is where freshness and performance collide. If a cached entry expires too soon, the system loses much of the benefit. If it expires too late, users or services may keep seeing stale content, stale policy, or stale authorization decisions.

Consistency problems usually appear when one component updates the source of truth but another component still serves an older cached value. That can create confusing behaviour, especially when multiple tiers cache the same object or when the cache is shared across requests, sessions, or tenants. Good cache design makes the freshness rule explicit rather than assuming the application will “just know” when a value is no longer valid.

Security implications of cached data

Caches can amplify exposure when they store sensitive content, especially if the cache key is too broad or the cache-control logic is too permissive. A response intended for one user can be replayed to another user if the system does not vary the cache correctly on the fields that matter. That is why cached responses, tokens, and session-related material must be treated as security-relevant data, not merely as performance artefacts.

Cache poisoning is another important failure mode. If an attacker can influence what is stored, the cache may distribute malicious or misleading content at scale, turning a performance layer into a propagation layer. For that reason, caches need clear trust boundaries, careful input handling, and rules that prevent untrusted variation from becoming globally reusable.

Risk and Threat Considerations

Caches create material risk when stale data changes a security decision, when a shared cache leaks one user’s content into another user’s response, or when poisoned entries are reused at scale. The same speed feature that improves resilience can also make a bad entry spread faster than a direct origin compromise would.

Failure mechanism: Weak cache keys, missing invalidation, or overbroad sharing allow stale, sensitive, or attacker-influenced content to persist beyond its safe lifetime and be served to the wrong requester.

Impact: The result can be data exposure, incorrect application behaviour, corrupted trust in responses, and in some architectures a durable attack path that survives until the cache is flushed or corrected.

Practitioner Guidance

Why practitioners should care: Cache behaviour is a control surface, not just a performance setting. Teams should know which data is cacheable, how freshness is enforced, and which requests or identities can legitimately receive a shared response.

What to watch for: Unexpected stale reads, user-specific data appearing in shared responses, cache miss spikes after deployment, and differences between origin behaviour and cached behaviour are all signals that the cache policy or keying model needs review.

Practitioner takeaway: Treat cache rules as part of application correctness and security design, especially wherever responses differ by user, privilege, session, or tenant.

Related resources from NHI Mgmt Group

• What is the difference between request-scoped caching and a shared application cache?
• Why can file-integrity checks miss page-cache corruption exploits?
• How should security teams distinguish DNS cache problems from identity access failures?
• When should teams clear DNS cache during incident response?