A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Fix a stale permission cache security bug

Explains why cached authorization decisions are risky and how to bound or invalidate permission-related cache safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would treat this as an authorization bug, not just a cache bug. Permission and membership caches need much stricter freshness rules than normal read data. The immediate fix could be a shorter TTL, explicit invalidation on membership change, and making sure cache keys include user, tenant, and relevant role or permission version.

Full answer below

Practice focus

Authorization freshness, revocation, cache scope, fail-safe behavior, invalidation, and security monitoring.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A stale permission or membership cache can preserve access after revocation and become a cross-tenant security incident. Authorization freshness, key scope, invalidation, and high-risk bypass rules must be stricter than ordinary response caching.
I would treat this as an authorization bug, not just a cache bug. Permission and membership caches need much stricter freshness rules than normal read data. The immediate fix could be a shorter TTL, explicit invalidation on membership change, and making sure cache keys include user, tenant, and relevant role or permission version.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would look at where authorization is enforced. The API should still check the current principal and resource ownership server-side. If permission decisions are cached, I would prefer caching inputs or permission versions briefly rather than caching broad allowed responses. On revocation, I would delete affected keys or bump a version so old keys stop matching. For sensitive actions, I may bypass cache and read the authoritative permission state.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating cached permissions like ordinary cached reference data.
Using keys that omit user, tenant, or permission version.
Relying on the UI to hide revoked access.
No audit or incident review after stale authorization.

A user loses access to a tenant, but the API still allows access for a few minutes because permissions were cached. How would you fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement