A pattern I keep running into: the API handler checks that the user can export the report, delete the project or send the invoices, then drops a job on a queue and returns 202. The worker picks it up later and does the work with a service account that can touch everything.
That check happened at enqueue time. If the job sits in the queue for an hour, or retries over a day, the user could have been removed from the org, lost the admin role, or had the project moved to another workspace in the meantime. The worker never asks again, so the action still goes through.
A few things that have helped on teams I've worked with:
- Put the acting user ID and tenant ID in the job payload, never only the object ID. A job without an actor is impossible to audit later.
- Re-check the permission in the worker right before the side effect, using current data. The handler check stays for fast feedback; the worker check is the one that counts.
- Decide what a failed re-check means. Usually it's "drop the job and log it", not "retry", or you get a retry loop that keeps hitting a 403.
- Scope the worker's credentials per tenant where you can, so a bad payload can't reach another customer's rows.
- For scheduled jobs (nightly exports, recurring emails), store who created the schedule and check that person still has access on each run. Schedules outlive the people who set them up more often than you'd think.
The test I like: create the job, revoke the user's role, then run the worker. If the export still lands in their inbox, the queue is acting with more permission than the user has.
How do you handle this? Do your workers re-check per job, or do you trust the enqueue-time check and keep queues short?
Top comments (0)