Fictional example. No client data.
This educational sample was created on . The application, accounts, finding, evidence, and remediation scenario are invented. It is not a redacted client report, a case study, a real test result, or a promise of the exact contents of every engagement.
The example demonstrates how to communicate a finding. Actual scope, methods, risk ratings, evidence handling, and verification are agreed for each engagement.
Executive summary
Fictional system: a customer document portal used by two synthetic tenants, Cedar and Willow. The test objective is to determine whether an authenticated user can access a document belonging to another tenant.
Illustrative conclusion: the example describes an authorization failure in a document-download workflow. The application recognizes a valid user session but fails to check whether the requested document belongs to that user’s tenant. In this scenario, that would permit cross-customer disclosure.
Recommended decision: prioritize a server-side authorization correction, examine related object-access workflows, and verify the boundary before treating the issue as closed. The scenario does not establish that any real customer data has been accessed.
Scope and limitations
- Illustrative target
- A fictional staging portal at
portal.example.testwith synthetic records. - Starting access
- One ordinary test user in each of two tenants. No administrative privileges.
- Included workflow
- Authentication, document listing, and a single document-download authorization boundary.
- Excluded activity
- Production systems, real customer records, denial-of-service testing, third-party infrastructure, and social engineering.
- Coverage limit
- Other APIs, roles, exports, and administrative workflows are not evaluated in this example. A passing result in one workflow would not establish security of those other paths.
For a real test, the report would identify the authorized asset inventory, test dates, environment/build, methodology, constraints, and any access or coverage changes that affected the conclusions.
EX-01: Missing tenant authorization on document download
Illustrative priority: High. This qualitative rating assumes a low-privilege user can retrieve a sensitive document owned by another tenant. It reflects the fictional scenario’s confidentiality impact and access prerequisites. No CVSS score or actual vulnerability is claimed.
Expected and observed behavior
The server should check the authenticated actor’s permission to access the specific document on every request. In the invented example below, a Cedar user is able to receive the synthetic document assigned to Willow.
| Check | Expected result | Invented result |
|---|---|---|
| Cedar user requests Cedar document | Permitted under the user’s role | Permitted |
| Cedar user requests Willow document | Denied; no document content returned | Willow’s synthetic content returned |
| Unauthenticated request | Denied | Denied |
The third row shows why a login check alone does not resolve the finding. Authentication identifies the user; authorization must also establish whether that user may access the requested object.
Evidence a real report should preserve
- The affected build and workflow, test role, tenant ownership, and authorized prerequisites.
- Redacted request/response references sufficient for the engineering owner to reproduce the issue.
- A clear distinction between what was demonstrated and the broader impact inferred from it.
- Protected handling of evidence, with secrets and unnecessary customer information removed.
Relevant testing reference: OWASP guidance on testing insecure direct object references.
Remediation plan
- Correct the authorization boundary. Check the actor, tenant, object, and requested action on the server before returning any document content. Return a consistent denied response when authorization fails.
- Inspect adjacent paths. Apply the same review to previews, exports, batch downloads, and other routes that retrieve tenant-owned objects.
- Add meaningful regression coverage. Exercise permitted access, cross-tenant access, role changes, revoked access, and unauthenticated requests.
- Verify operational implications. Have the responsible team review relevant access records and decide whether a separate investigation is warranted. A test finding alone cannot establish the history of exploitation.
Example owner: the application engineering lead, with security support. In a real report, the organization would assign a named accountable owner and a remediation date based on its exposure and risk decision.
Verification criteria
Example status: open; not retested. No correction or retest has actually been performed. The example would be ready for verification once the engineering owner identifies the changed build and deployed environment.
- The original cross-tenant request returns no unauthorized content.
- Allowed same-tenant access still works for the intended role.
- Equivalent access paths enforce the same tenant and role boundary.
- The final report records the retest date, build, evidence, outcome, and remaining limitations.
Closing this finding would mean the agreed verification checks passed. It would not imply that every feature or future software change is secure.
Read the guide to penetration test scope and cost, or explore penetration testing services.