API access revocation testing for queued work

What happens if a person loses access after an API accepts their request but before a queued job finishes? The answer depends on the product's explicit revocation policy. A receiving team should test the request, the worker's later action, and access to any resulting artifact. A 202 Accepted response or a denied download alone cannot prove that protected data was never read or written.

This guide is for an engineering lead or prime contractor accepting an application with background jobs, exports, scheduled actions, or delayed writes. It is a focused extension of the general software subcontractor acceptance checklist, not a security certification or a replacement for a full penetration test.

Decide what revocation means before writing a test

The product owner should choose the policy for each operation. An export requested by a person may need to stop when that person loses access. An organization-owned report might continue under a separately authorized service identity. Neither outcome follows automatically from using a queue.

Write the policy at three decision points:

The choices in this table are proposed engineering decisions, not a claim that one timing rule is mandated by a standard. They should be agreed in the scope and acceptance criteria. OWASP's authorization guidance calls for permission checks on every request and a deny-by-default posture. A worker and a later download are separate access points whose policy needs to be explicit.

Build a fixture that can show both failure and success

Use synthetic data in a review environment. Create tenants A and B, one report in each, an A member who may export A's report, an A viewer who may read but not export, and a B member. Keep the report names similar so an accidental cross-tenant lookup is visible. Give each result a distinct marker that can be checked in a file without using customer data.

The following is an illustrative test contract, not a test of a Rainier client system. Assume this product chooses current requester authority at worker execution and current authority again at download. If a different policy is justified, replace the expected results before running the tests.

The wrong-object test addresses OWASP API1:2023, broken object level authorization: an endpoint may be valid for the user while the supplied object identifier is not. The viewer/export distinction addresses OWASP API5:2023, broken function level authorization. If report fields have separate visibility rules, add a field-level test using OWASP API3:2023. A guessed identifier, a hidden button, or a role name is not itself an authorization decision.

Run the pause-and-revoke test

The key test is controlled timing. In a test environment, stop the worker immediately before it loads the target report. Submit the export as the authorized A member and confirm the job is queued. Change that member's role or remove membership through the same administrative path used in the product. Resume the worker and observe the actual data read, object storage write, job state, and any notifications. Then try both the normal download endpoint and any direct file link the workflow produces.

Record the exact checkpoint. A test that revokes access after the worker read the report answers a different question from one that revokes before the read. If the job uses a service identity, identify the policy that permits it to continue, the tenant and data scope it may use, and who can retrieve the result. Do not let “the queue is trusted” stand in for that decision.

Include an allowed control after each denial test. Otherwise a worker that rejects every job can appear secure while the product is broken. If revocation is eventually consistent, document the promised bound, instrument the moment each service sees the new state, and test that bound. Do not silently treat an unexplained delay as success.

Inspect effects beyond the response code

For each case, keep a short evidence row with: tested build and environment; actor, role and tenant before and after change; report identifier; job and request IDs; checkpoint and timestamps; expected policy; API response; worker decision; database reads and writes; file existence and scope; download result; and reviewer disposition. Redact secrets and customer data from the record.

The denial is incomplete if an A file was written into a B-visible storage path, even if the download endpoint later returns 403. Likewise, an API can reject a request after it has already enqueued an unauthorized job. Inspect queue and storage state, not just HTTP status. OWASP's multi-tenant guidance discusses tenant-scoped data access and authorization matrices; the three-stage evidence record here applies that boundary to a delayed operation.

Retry behavior is a separate acceptance concern. A job may be redelivered or a client may repeat a request after a timeout. Use the API retry and idempotency test guide to decide whether repeated attempts create more than one business effect; then add the revocation state to those cases. A valid idempotency key must not become a lasting permission grant unless that is the explicitly reviewed product policy.

Decide whether the increment is ready

The acceptance owner can use four outcomes: pass when all agreed cases have observable results; fix when a forbidden effect occurs; conditional when the policy is agreed but a bounded test or integration dependency remains; and unreviewed when the expected policy or evidence is missing. Record who owns the next action and the retest build. A screenshot of a denied UI control is insufficient for a worker or file access claim.

Rainier's published Noonlight engagement describes our ownership of authentication and role-based access control for an internal operations dashboard. It does not report this queue test, its results, or Noonlight's revocation policy. The worksheet above is a proposed way to scope and accept a new application or integration work package. Our software subcontracting service explains how we define those boundaries with a prime; bring the workflow, roles, and delayed operations to a scoping conversation.

Discuss an API work package→