01 / Executive summary
Example: customer request portal
In this synthetic example, the complete fictional small portal was reviewed. One request-details check found that a test user could view another test user’s request. Restrict that access before using real customer data.
- Scope
- One complete fictional website and hostname · Five route types · Two API operations · Public access and two authenticated test roles
- Outcome
- Completed · One finding confirmed
- Priority
- Correct the object access check, then retest with both test users.
02 / Coverage and limitations
What we tested.
What we couldn’t reach.
| Area | Boundary | Result |
|---|---|---|
| Home · / | Configuration and input handling | Performed · Synthetic evidence R-01 |
| Sign-in · /sign-in/ | Input handling and sessions | Performed · Synthetic evidence R-02 |
| Request list · /requests/ | Access control | Performed · Synthetic evidence R-03 |
| Request details · /requests/{id}/ | Access control | Performed · Finding F-01 |
| Profile · /profile/ | Input handling and access control | Performed · Synthetic evidence R-05 |
| GET /api/requests | Access control | Performed · Synthetic evidence A-01 |
| GET /api/requests/{id} | Access control | Performed · Finding F-01 |
This fictional inventory includes all pages and features of the example site, rather than selecting one workflow. Evidence labels are illustrative; no assessment was performed. Hosting infrastructure and third-party provider systems are outside this example. An included check that cannot be performed must be recorded as blocked and receive a limited closeout. The review covers the accepted inventory using agreed checks, access and time. It does not assess every possible attack path or establish that the application is free of vulnerabilities.
03 / Confirmed finding · Fictional
F-01 / A request can be read by the wrong user.
- Severity
- High in this example, because private request contents cross the intended user boundary.
- Affected area
- The request-details page and related API operation within the complete fictional site.
- Evidence
- Two authorized test accounts were used. The first account could retrieve a request created by the second account by changing the request identifier. Synthetic test data was used.
- Impact
- An authenticated user could read another user’s private request if they obtained its identifier.
- Repair guidance
- Enforce ownership and organization membership on the server for every request lookup. Return a safe denial when access is absent. Add regression checks for both roles and cross-user access.
- Retest
- Repeat the agreed access checks with both test users after the developer confirms the fix.
04 / A final report for each outcome
Clarity even when
the result is limited.
No confirmed findings
The report records the checks performed and their boundaries. No confirmed findings does not establish that the application is free of vulnerabilities.
Incomplete or blocked work
The report separates completed checks from areas that could not be assessed, explains the access or scope limitations and recommends the next step.
05 / Your next step
A practical repair plan.
Your developer can use the evidence and recommended checks. If you want studio help, request a separate proposal covering named findings, regression checks and deployment responsibilities. Monthly care is a separate opt-in.
Request a security review →