What you actually receive.
A redacted example of a penetration test report. Same structure, scoring and evidence as a real engagement, with client data removed and findings made generic. If the report is the product, this is the product.
Illustrative sample. Not a client report, and not a template you can reuse.
Download as PDFPenetration test report
Example Client, web application and API
Reference
PT-2026-014
Confidential
The assessment covered the customer portal, the public API and the admin console, tested from three roles. Eight findings were confirmed, one of them critical: an object-level authorization flaw allowed any authenticated customer to read another customer's invoices by changing an identifier.
The critical and both high findings were fixed during the engagement and verified in the retest window. Two remain open: one medium, one low accepted as risk.
- Critical1
- High2
- Medium3
- Low2
- Assessment window
- 6 to 17 October 2026
- Report issued
- 20 October 2026
- Retest
- 3 November 2026
- Roles tested
- Customer, support, admin
| Target | Environment | Notes |
|---|---|---|
| app.example.com | Staging, production parity | Customer and admin roles |
| api.example.com/v2 | Staging | REST and GraphQL |
| cdn.example.com | Production, read-only | CDN and storage review |
| ID | Finding | Severity | Status |
|---|---|---|---|
| F-01 | BOLA on invoice endpoint | Critical | Fixed |
| F-02 | JWT key confusion in auth service | High | Fixed |
| F-03 | Public bucket policy on assets CDN | High | Fixed |
| F-04 | No rate limit on password reset | Medium | Fixed |
| F-05 | Verbose error messages | Medium | Open |
| F-06 | Session not invalidated on logout | Medium | Fixed |
| F-07 | Missing security headers | Low | Fixed |
| F-08 | Username enumeration | Low | Accepted |
Broken object-level authorization on invoices
CVSS v3.1
8.1
Vector
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Affected
/api/v2/invoices/{id}
Status
Fixed, verified
The invoice endpoint resolves records by identifier without checking that the record belongs to the authenticated customer. Any valid session can read another customer's invoice, including billing address, line items and the last four digits of the payment method.
Reproduction
- Authenticate as customer A and create an invoice.
- Capture the invoice identifier from the response.
- Authenticate as customer B and request the same identifier.
GET /api/v2/invoices/8841 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token for customer B>
HTTP/1.1 200 OK
{
"id": 8841,
"customer_id": "cus_A",
"total": "1,240.00",
...
}Impact
Disclosure of billing data for any customer, including partial payment details. Enumerable identifiers make the exposure systematic rather than opportunistic.
Remediation
Enforce ownership at the data-access layer, not in the controller. Scope every invoice query to the authenticated customer, return 404 rather than 403 for records outside their scope, and add a regression test per resource type.
Retest
Replayed on 3 November 2026 against the same two accounts. Customer B now receives 404. Closed.
End of sample. Real reports contain every finding in this format, plus an appendix of raw evidence and a remediation roadmap.
Want a report like this about your system?
Send the scope and the deadline. You will get a fixed quote, a start date and the same structure of evidence at the end.
Typically replies within one business day. NDA on request.
hello@enesismaili.com