Proving a cross-tenant data exposure before a SaaS feature ships

The situation

The platform is about to release a bulk-export endpoint that lets a customer download its records as a file. Automated checks in the build pipeline have passed. But nothing in those checks knows which tenant should own which record, so the team wants a human to test tenant isolation before customers rely on it.

Scope and rules of engagement

In scope: the new export endpoint and the API calls behind it, tested with test accounts in two separate tenants, A and B, in a staging environment. Out of scope: production data and denial-of-service testing.

What we tested

Working as a valid user in Tenant A, the tester maps every place an object reference reaches the export flow (path parameters, query strings and the request body) and replays each request with references that belong to Tenant B.

The finding

One request returns Tenant B’s records to Tenant A’s session. The server checks that the user is logged in, but not that the requested records belong to the user’s tenant. This is broken object-level authorization (OWASP API1:2023, CWE-639: authorization bypass through user-controlled key).

Severity reasoning. CVSS v3.1 scores what an attacker needs and what they gain. Here the flaw is reachable over the network, takes no special conditions, needs only an ordinary account in any tenant, needs no user interaction, and exposes another tenant’s records in full. The tester records the scope as changed, because the tenant boundary is the isolation the platform promises. That gives CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, a base score of 7.7, rated High. A reasonable assessor could instead leave the scope unchanged, which scores 6.5 (Medium), so a good report states the choice and the reason. If the same missing check also let a user change or delete another tenant’s records, integrity impact would be High as well and the score would reach 9.6, Critical. In this scenario the export endpoint only reads, so the rating stays High.

The proof

The finding includes the exact request sent as Tenant A, the response containing Tenant B’s data (redacted), and numbered reproduction steps a developer can follow with their own two test accounts. With that proof in hand, nobody has to argue about whether the finding is real.

Remediation guidance

Derive the tenant from the authenticated session, never from the request. Enforce an ownership check on every object the export reads, in one shared authorization layer rather than per endpoint. Add automated tests that call the endpoint with another tenant’s IDs and expect a denial. Non-sequential IDs make enumeration harder but do not fix the flaw on their own.

Retest to verified fix

After the fix is deployed to staging, the tester replays the original requests and the variants (path, query, body and batched IDs) as Tenant A. In this scenario every request for Tenant B’s data is now refused and returns no records, so the finding is closed with the retest evidence attached.

How it shows up in the platform

• Findings: severity, CVSS, CWE, proof and evidence, reproduction steps and remediation guidance in one record.
• Remediations: an owner, a status and an SLA for the fix.
• Integrations: findings can be pushed to Jira or ServiceNow, so the fix is tracked where the developers already work.
• Retests: the verification that confirms the fix instead of assuming it, kept with the original finding.
• Reports: the written report your stakeholders and auditors read, built from the same findings and evidence.

What to take away

• A 200 OK returning someone else’s data looks exactly like a legitimate response. That is why this class of bug needs a human with two accounts.
• Proof turns a “maybe” into a fix.
• A finding is not done when it is reported. It is done when the retest says so.