Sample security review report

Engagement summary and scope

Illustrative application: Nimbus Notes, a multi-tenant notes product with an AI assistant. The example scope covers the authenticated notes API with two test tenants and member and administrator roles. Testing dates and the final workflow list would be recorded in an actual report.

Exclusions: third-party billing, infrastructure testing and availability testing. The assistant’s retrieval and tool flows are outside this shortened example; no conclusion is drawn about them.

Executive summary

The example API accepts a valid session but does not enforce tenant ownership on note reads. A member of tenant A can read a note owned by tenant B. The remediation is to authorize each resource lookup using the caller’s server-side identity and tenant.

The initial finding and the illustrative retest are recorded separately below, so a reader can distinguish the original exposure from the result after remediation.

Finding 01: Cross-tenant note access

Severity

High in this illustrative scenario

Initial status

Open at initial report

Affected operation

GET /api/v1/notes/{noteId}

Required access

An authenticated member in another tenant

Reproduction and example evidence

1. Create a note using the tenant-B test account and record its identifier.
2. Use the tenant-A test account’s session to request that identifier.
3. Observe that the API returns tenant B’s note body.

# Illustrative request using tenant A’s session
GET /api/v1/notes/N-20077
Authorization: Bearer <tenant-A-test-session>

HTTP/1.1 200 OK
{"id":"N-20077","tenant":"B","body":"Tenant B test note"}

Impact and root cause

In this example, an authenticated user who knows a note identifier can read another tenant’s note. The handler loads the note by identifier and checks only that a session exists. It does not enforce the resource’s tenant boundary.

Recommended remediation

Scope the lookup to the tenant derived from the authenticated server-side session. Return no note when it is outside that scope. Apply equivalent authorization to update, delete and export operations, and add cross-tenant regression checks alongside legitimate access checks.

Retest record

Illustrative result: passed for the original read-access issue. After the example fix, the cross-tenant request returns 404 without a note body. Tenant B can still read its own note.

A real retest records the tested build or version, date, evidence and remaining limitations. Passing these checks does not establish that unrelated endpoints are secure.

Customer summary and limitations

The plain-language summary would describe the agreed scope, testing window, findings and retest status without exposing sensitive reproduction details. An actual engagement is time-boxed and cannot establish the absence of all vulnerabilities.

A one-time Security Review includes one retest of agreed fixes. Customer requirements should be shared during scoping; a report is not a compliance certification and acceptance is the customer’s decision.

For captured lab evidence, see the application security case studies. For service coverage, see AI and LLM testing and SaaS and API reviews.