Carry Tenant Context Into Async Jobs
Bind each background job to a trusted tenant and recheck permission before sensitive work.
A background worker does not receive the browser session that started a task. It receives a queue message, often hours later and under a service credential that can read every tenant. If that message contains only a record ID, the worker may have no reliable way to enforce the original boundary. OWASP multi-tenant guidance applies to these asynchronous paths as much as to request handlers.
Define the job envelope
Record the operation, tenant ID, initiating principal, target resource, authorization decision reference, creation time, and schema version. The producer must derive these values from trusted server state. A client may request an operation, but must not choose the tenant or privilege level placed in the job.
| Transition | Check |
|---|---|
| API to queue | Was the caller allowed to start this operation? |
| Queue to worker | Is the envelope complete and authentic for this queue? |
| Worker to database | Are queries bound to the recorded tenant? |
| Worker to output | Is the result stored and delivered to the right tenant? |
| Retry | Is the operation still safe and idempotent? |
A stored authorization decision can explain why work began. It does not always grant authority forever. For a delayed export or destructive action, decide whether the worker must recheck current membership. Write the rule down. Then test a job queued just before revocation with synthetic accounts.
Use Tenant A and B records with different markers. Start an A job, inject a benign queue delay in the owned test system, and confirm the worker reads only A records. Test missing tenant context, a stale schema, and an unknown resource. Each must fail closed without producing a cross-tenant artifact. Check the output file or notification, not only the worker log.
Handle delayed work
Illustrative queued export: {version: 1, action: "export", tenantId: "tenant-a", actorId: "user-a", recordId: "record-a", decisionId: "grant-7"}. At execution, resolve record-a from storage and require its owner to equal tenant-a. For an export that requires current membership, recheck user-a before the worker reads rows. In the fixture, revoke user-a before delivery; require a stopped job, no file, and a bounded denial event. A different continuation policy needs an explicit owner decision and test.
AWS tenant isolation strategies describe pooled systems where application policy carries isolation. A broad worker identity makes that policy especially important. This job-envelope artifact tells reviewers where the tenant decision travels. It does not replace a per-operation permission rule or permission to test a customer environment.
Find the gaps in your access controls
See how an illustrative cross-workspace finding connects evidence, impact and a fix. Discuss the tenant boundaries your team needs reviewed.