The application correctly hides another team’s records in its main screen. An export request accepts a record identifier directly and queues a job. If that path omits the same access decision, the screen can look secure while the export exposes the data.
Check access to the requested data
Create a synthetic application with two teams and records owned by each. An allowed user can view and export their team’s records. A direct request naming the other team’s record must be evaluated against the actual object and operation.
OWASP’s authorization guidance recommends checking permissions on every request, denying by default and testing access-control logic. For this example, the check needs the authenticated identity, the requested record and the export action. An opaque identifier or a hidden link does not replace that decision.
Source: OWASP · Authorization Cheat Sheet.
Define permissions for background work
An export may run after the initiating request finishes. Carry a trustworthy reference to the authorization context into the job, and define how current policy applies when execution begins. If project membership changes while work is queued, the system needs an explicit rule for whether the job may continue.
Avoid relying on an unrestricted worker account as the answer to every access question. The worker may require technical access to storage while the business operation still needs a narrower authorization decision. Record the initiating identity and relevant scope without placing credentials or private record contents in ordinary logs.
Protect completed files
The generated file has its own access path. A correct check at request time is incomplete if anyone who obtains the download address can retrieve sensitive output beyond the intended access policy. Decide how the file is served, how long it is available and what happens when the requester loses access.
Test a completed export as well as a newly queued one. Include filenames, progress responses and error messages in the review; those can disclose information even when the full file is denied.
- An allowed user can request and retrieve the intended export.
- A direct request for another team’s record is denied.
- A queued operation follows the defined membership-change policy.
- The generated file enforces its documented download access and lifetime.
Learn from denied and failed requests
Run these cases with disposable records and inspect the response, job state and storage result. A denied request should not leave a broadly accessible file behind. An abandoned job should not become a permanent source of private output.
Authorization is easier to reason about when every transition has a named decision. Follow the data from screen to request to worker to download, and identify which component owns each check.