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:
issuerefreshrevokeexpire
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.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.