I Built a Tool to Detect Delayed Access Revocation

Kshitij — Sun, 09 Aug 2026 20:16:36 +0000

This weekend, I built TimeTrap.

It started with a simple question:

What if access is revoked, but something that depends on it stays active?

That small delay can become a real security problem.

🔗 Try TimeTrap live

💻 View the source code

The problem

Imagine a user cancels a premium subscription at minute 10.

The subscription is revoked immediately, but a cached permission remains active until minute 60. The system allows a five-minute grace period.

So the timeline looks like this:

Time	What happens
Minute 10	Subscription is revoked
Minute 15	Allowed grace period ends
Minute 60	Cached access finally expires

The user keeps premium access for 50 minutes after cancellation. Of those, 45 minutes violate the rule.

Each part of the system may look correct by itself. The subscription was revoked, and the cache eventually expired. The problem is the gap between those two events.

That is what TimeTrap finds.

What TimeTrap does

You describe the objects in your authorization flow—subscriptions, caches, sessions, or tokens—and add events such as:

issue
refresh
revoke
expire

Then you choose a rule, such as “cached access must end within five minutes of subscription revocation.”

TimeTrap checks the timeline and shows:

whether the scenario is safe;
the exact time the violation begins and ends;
how long stale access remains active;
the events that caused the problem;
a suggested correction.

For the example above, TimeTrap reports the violation as [15, 60) and suggests revoking the cached permission when the subscription is revoked.

You can see the complete flow here:

How it works

The analyzer is written in Go and is fully deterministic. The same input always produces the same result.

Instead of checking every minute, it checks only the moments where something can change: an issue, refresh, revocation, expiry, or rule deadline. It then joins failed periods into one clear violation interval.

The rest of the application uses:

React and TypeScript for the interface;
Go for the API and analyzer;
PostgreSQL for saved scenarios and results;
Zerops for deployment.

Saved results use their own URLs, so they can be refreshed or shared. Applying a fix creates a corrected copy instead of replacing the original unsafe result.

What I learned

Authorization is not only about who can access something. It is also about when that access should stop.

TimeTrap is currently a design-time tool. It checks the scenario you provide; it does not inspect or change a live production system. The model is intentionally small and uses integer-minute timing, but it makes this easy-to-miss problem visible.

OpenAI Codex helped me with planning, implementation, testing, documentation, and deployment. I still reviewed the code and verified the behavior through tests, builds, API checks, and browser testing.

I built TimeTrap for the WeMakeDevs challenge and deployed it on Zerops.

If this kind of authorization problem sounds familiar, try the demo and let me know what you think.

👉 Open TimeTrap

⭐ Explore the GitHub repository

DEV Community: Kshitij

I Built a Tool to Detect Delayed Access Revocation

The problem

What TimeTrap does

How it works

What I learned