Cross-Tenant IDOR During a SaaS Pen Test
PenTest Collective has a signed statement of work to test the customer portal of Meridian Health, a SaaS provider, between 01:00 and 05:00 UTC. The scope lists app.meridian.example and its staging tenant, with one test account per role. Production API api.meridian.example and all customer data are explicitly out of scope. During testing, the tester finds an insecure direct object reference in a staging API call that returns a production patient record when the tenant ID is changed. The response includes a name, date of birth, and insurance member ID. The tester has already made three requests to confirm the issue. The client security contact is offline until 08:00, but a junior developer in the chat channel asks the tester to grab a few more records to prove impact. The tester contract says any suspected data exposure must be reported within one hour to the client incident hotline, which is answered 24/7.
1. What should the tester do immediately after the third request? Justify each action.
Read the worked answer
Stop testing and do not make a fourth request. The third response already proves the IDOR; more records would increase the unauthorized exposure and could be characterized as intentional access beyond scope. Immediate actions:
- Do not save, forward, or paste the patient record into chat, email, or the report. If the tooling auto-saved it, preserve it only in an access-controlled evidence folder and record a hash; do not open it repeatedly.
- Record minimal metadata: UTC timestamps, endpoint, request method, status code, tenant ID values tested, and the fact that a name, DOB, and member ID were returned, without reproducing them.
- Call the 24/7 incident hotline within the one-hour contractual window. State that production data was accessed through a staging API and that three records were exposed.
- Tell the junior developer that you cannot grab more records and that the request must come from the authorized security contact.
- Do not delete evidence, but do not retain PII longer than the contract allows; follow the client instruction under legal direction.
2. How should the finding be written in the report without reproducing patient data? Include what to redact and how to show impact.
Read the worked answer
Write the finding as an access-control defect, not as a data dump. Include:
- Title: Staging API IDOR exposes production patient records across tenants.
- Affected endpoint and parameter, with a synthetic example such as tenant_id=REDACTED-1 changed to REDACTED-2, not a real record.
- Evidence: request sequence, HTTP status, response size, and a redacted field list (name, DOB, member ID present) with no values.
- Scope: exactly three records accessed, timestamps, tester identity, and a statement that no further requests were made.
- Impact: an authenticated staging user could read production PHI; note the staging-to-production trust boundary failure.
- Remediation: enforce tenant authorization server-side, separate staging credentials from production data, add object-level access checks, and log or alert on cross-tenant access.
- Retain a redacted screenshot only if the client requires it; blur or replace all identifiers. Attach a data-handling attestation.
3. The junior developer asks for the record to verify. How do you respond, and what contractual and ethical principles apply?
Read the worked answer
Refuse the junior developer request. Need-to-know and data minimization apply: a developer in a chat channel is not the authorized incident handler, and chat is not an approved channel for PHI. Say: I cannot share the record. The finding is confirmed with three requests, and the incident hotline has been notified. Please route any verification request through the security contact. Contractual principles: stay within the statement of work, report suspected exposure through the designated channel, avoid unauthorized access, and preserve confidentiality. Ethical principles: do not use client data to prove a point; do not let urgency from a non-authorized person expand scope. If the client later needs verification, provide a redacted request and response pair or a screen-share with the handler, under written authorization, and log who viewed it. The tester obligation is to prove the defect, not to distribute the evidence.