{
  "id": 7235769,
  "title": "Your Cache Is Part of the Security Model",
  "url": "https://urgent.news/2026/09/14/your-cache-is-part-of-the-security-model",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-14T03:39:56.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/anusha_mukka/your-cache-is-part-of-the-security-model-44n2"
  },
  "original_language": "en",
  "account": "Caching is often introduced with the goal of improving performance. However, when cached data influences authorization outcomes, it plays a crucial role in determining how long an outdated security fact can remain in use. This is the fourth installment in a series examining the intersection of security design and production systems. While caches aim to accelerate authorization, they can inadvertently maintain old permissions even after the source of truth has revoked them. This issue typically arises inadvertently rather than as a deliberate security choice.\n\nTeams may add caching to reduce latency from an identity service or store authorization decisions for an extended period. While these changes can enhance performance, they can inadvertently prolong the lifespan of outdated security information. When a user changes departments or a device falls out of compliance, the authorization path may still rely on yesterday's cached answer rather than the current state. At this juncture, the cache configuration can effectively become an access-control policy.\n\nCaches can be differentiated based on the type of data they store. Caching a policy bundle allows the system to evaluate the current request, whereas caching an attribute carries the risk of storing outdated information. A cached \"allow\" decision preserves both the old inputs and the old conclusion, which can pose security risks if not managed properly. To address this, an example caching key is provided: cache_key = (subject_id, resource_id, action, policy_version, attribute_generation). If a cache decision does not capture policy and attribute versions, it cannot determine when its answer has become obsolete.\n\nDifferent attributes require different cache lifetimes. For instance, a display name may become stale without affecting authorization, while employment status must be current. Device posture might change frequently during the workday, necessitating more frequent updates. Assigning a single cache lifetime to all attributes can mask these differences. The appropriate lifetime is determined by the operation's risk and the behavior of the source system. These values should be defined by policy rather than a uniform time-to-live (TTL).\n\nWhen an allow decision is cached for an extended period, it can preserve access after revocation. This asymmetry between stales denies and allows is why long caching periods for allow decisions are generally avoided. When feasible, revocation events should invalidate the affected entries, continuing to use the normal TTL for the remaining entries. Event delivery failures should be anticipated, and a strategy to handle such scenarios should be in place.\n\nThe cache invalidation process typically involves invalidating by subject, which is straightforward but may be resource-intensive. An alternative is to invalidate by changed fields, which is more targeted but requires each policy to declare its dependencies. The choice between these methods depends on the system's scale and risk tolerance. When the identity source is unavailable, a cache miss is evident, but a stale hit can be more dangerous as it appears successful. Implementing a soft expiry and a hard expiry for cached values can mitigate this issue. After the soft expiry, cached values can be served if policy permits, with the system refreshing in the background. After the hard expiry, the documented failure posture for the operation should be used.\n\nIn the event of an outage, a cache miss is immediately apparent, but a stale hit can cause serious security problems. To address this, cached values should have both a soft and hard expiry. If a value exceeds the hard expiry, the system should use the documented failure posture for the operation. The authorization decision should be aware that the cached value is stale to prevent it from being treated as current. When questioned about a decision, the evidence should indicate whether each significant attribute came from a live source or a cache, along with the observation time and age of the cached data. Sensitive raw values should not be included in broadly accessible logs but can be protected where necessary.\n\nTesting the cache is crucial to ensure its reliability. Authorization tests should include scenarios where a cached \"allow\" decision is followed by revocation. Additionally, tests should consider what happens if the invalidation event is delayed, helping the team understand the maximum exposure window. When reviewing cache configurations, it is essential to treat them with the same scrutiny as authorization rules. The responsibility for setting authorization-cache lifetimes can fall to various stakeholders, including performance owners, security owners, or the team that originally implemented the cache.",
  "summary": "Caching is usually introduced as a performance decision. Once cached data participates in an authorization result, it also determines how long an old security fact remains usable. This is Part 4 of Security Infrastructure in Practice, a series about what happens when security design meets production systems. Caches are supposed to make authorization faster. They can also keep an old permission…",
  "key_points": [
    "Caching can prolong outdated security facts by maintaining old permissions even after revocation.",
    "Different attributes require different cache lifetimes based on risk and source system behavior.",
    "Implementing soft and hard expiry for cached values mitigates risks of stale hits."
  ],
  "editors_take": "Caching plays a crucial role in security by determining how long outdated security facts remain in use, and its configuration can effectively become an access-control policy if not managed properly.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}