Your pentest provider asks for a login. You create an administrator account in a test organization and send it over. The tester can now explore the application, but the setup has left a central question unanswered: what happens when a member of one customer organization requests another customer's records?
OWASP's 2023 guidance on broken object-level authorization describes the underlying failure: an API accepts an object identifier without adequately checking the caller's right to act on that object. A user can be properly authenticated and still be asking for data they do not own.
If your application serves separate customer organizations, give the test separate customer organizations. Include accounts with different permissions inside them. The scope should let the tester examine the boundaries your customers depend on, including the paths that produce downloadable files.
Build a small example of the customer relationships
Consider a hypothetical invoicing product. Organization A has a billing administrator and a read-only employee. Organization B has its own administrator. Both organizations contain synthetic invoices, and the read-only role is explicitly allowed to view invoices but prohibited from creating exports.
Those rules are invented for this example. Your product team must supply the real ones before a tester can distinguish a defect from an intended feature.
| Caller | Operation | Expected result in this example |
|---|---|---|
| A billing administrator | Read an A invoice | Allowed |
| A billing administrator | Read a B invoice | Denied |
| A read-only employee | Read an A invoice | Allowed |
| A read-only employee | Start an A invoice export | Denied |
| B administrator | Download A's completed export through the application | Denied |
This follows the approach in OWASP's authorization testing automation guidance, reviewed September 18, 2026: express access rules across features, roles, and data, then test the combinations. The useful artifact is an expected result for each relationship, not merely a list of account names.
Agree on legitimate exceptions before testing. If your product supports shared workspaces or delegated access, provide a separate example of each. Otherwise, an engineer may dismiss an unexpected result as “sharing” without establishing that sharing was authorized.
Follow an export past the first request
An invoice export makes a useful test case because the request and the eventual download may be handled by different parts of the application. In our example, the API queues a job, a worker retrieves invoice data, and the browser later receives a file link.
OWASP's multi-tenant security guidance, reviewed September 18, 2026, calls for tenant isolation beyond the initial API check, including background processing and shared storage. Carrying an organization identifier in a job payload does not, by itself, establish that it belongs to the caller.
For the hypothetical test, create a distinctive synthetic invoice in each organization. Have A's authorized administrator request an export and inspect the resulting file for A's expected records. Then test whether B can access the job status or obtain the file through the application's download endpoint. Record any returned metadata as well as file contents; an error page does not undo information disclosed by an earlier response.
Repeat the relevant steps after removing the requesting account from A. First decide what the product promises when access changes during a queued export. If the intended behavior is to deny later downloads, verify that behavior explicitly. A test report should not silently invent the product's revocation policy.
A signed download link changes what you are testing
For S3-backed exports, AWS describes presigned URLs as bearer tokens: possession grants the permitted access while the URL and its underlying credentials remain valid. That documentation was reviewed September 18, 2026.
A valid presigned URL opening in a second browser is therefore not sufficient, by itself, to prove a tenant isolation bug. Ask how the second user obtained it. If B can make the application issue A's download link, the authorization failure occurs before S3 receives the request.
Decide whether a reusable link is acceptable for the exported data. If customer access must be checked at every download, a direct bearer link may not match that requirement. Put the decision in the test scope, together with the intended link lifetime and behavior after membership removal. Do not label expected storage behavior a vulnerability because the application contract was never written down.
Make the report show what was exercised
Request a scope appendix identifying the roles and customer relationships used in the test. For an export finding, it should describe the point where access was incorrectly granted and the affected operation, with synthetic evidence that an engineer can reproduce in the agreed test environment.
Record untested paths too. If a production-only support console or integration could not be exercised, keep that limitation visible when the report is sent to a prospective customer. “No findings” cannot resolve a boundary that was outside the engagement.
Before the next SaaS pentest starts, ask your product lead and tester to agree on the access matrix. If neither can state which customer may obtain a completed export, resolve that ambiguity before spending the testing hours.