Sample, public
Penetration test report
Sample Company Pvt Ltd
1. Managerial summary
Overall risk: moderate. The web app and API are well built in most places, but one access control flaw let any logged-in customer read other customers’ invoices. That issue alone could have exposed personal and commercial data for every customer.
Two high-severity issues were fixed within a week of the report, and both fixes held when we checked them on 3 October 2026. The remaining medium and low items are scheduled in the team’s normal work.
Fix first
- Check ownership on every object the API returns (finding H-01).
- Limit login attempts and add a second factor for admin users (H-02).
- Stop returning stack traces from the API in production (M-02).
- Critical0
- High2
- Medium3
- Low2
- Informational3
2. Scope and method
- In scope
- Web app at app.example.com and REST API at api.example.com, including two customer roles and the admin role.
- Out of scope
- The third-party payment provider, denial-of-service testing and social engineering.
- Environment
- Staging, with production-like data supplied by the client.
- Approach
- Automated attacks with best-of-market tools, then manual testing of every page and endpoint in scope.
- Standards
- OWASP Web Security Testing Guide, OWASP ASVS and the OWASP API Security Top 10.
3. Findings
| ID | Finding | Severity | CVSS 3.1 | After fix check |
|---|---|---|---|---|
| H-01 | Broken object level authorisation on the invoices API | High | 6.5 | Fixed and verified |
| H-02 | No limit on login attempts for admin accounts | High | 7.5 | Fixed and verified |
| M-01 | Session tokens stay valid after password change | Medium | 5.4 | Open, scheduled |
| M-02 | Stack traces returned by the API in production mode | Medium | 5.3 | Fixed and verified |
| M-03 | File upload accepts SVG files with scripts | Medium | 5.4 | Open, scheduled |
| L-01 | Software versions shown in response headers | Low | 3.7 | Accepted risk |
| L-02 | Password reset links valid for 72 hours | Low | 3.1 | Open, scheduled |
| I-01 | Content Security Policy could be stricter | Informational | None | Open |
| I-02 | Cookies missing the SameSite attribute | Informational | None | Fixed and verified |
| I-03 | Unused API version still reachable | Informational | None | Open |
Finding H-01
Broken object level authorisation on the invoices API
- Severity
- High
- CVSS 3.1
- 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Endpoint
- GET https://api.example.com/v1/invoices/{id}
- References
- OWASP API Security Top 10, API1 Broken Object Level Authorization; CWE-639
Summary
The API returns any invoice whose ID it is given, as long as the request carries a valid session. It does not check that the invoice belongs to the account making the request. Invoice IDs are sequential, so they are easy to guess.
Evidence
Logged in as customer A, we requested an invoice that belongs to customer B. Tokens are masked.
GET /v1/invoices/10482 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...[customer A, masked]
HTTP/1.1 200 OK
Content-Type: application/json
{"id":10482,"account":"customer-b","name":"[redacted]",
"billing_address":"[redacted]","gstin":"[redacted]","total":48200}Impact
Any logged-in customer could read every other customer’s invoices, including names, addresses and GST numbers. That is personal and commercial data, and its exposure would be a reportable breach under India’s DPDP Act.
Why we rate it High
The CVSS base score is 6.5, which CVSS calls Medium. We raise it to High because the data covers every customer, the IDs are guessable and exploiting it needs nothing more than a free account. The report always explains an adjustment like this.
Fix
- Check, on the server, that the requested invoice belongs to the account in the session, on every object lookup.
- Take the account ID from the session, never from the request.
- Add an automated test that requests another account’s invoice and expects a 404.
Fix check
Fixed and verified on 3 October 2026. The same request now returns 404 Not Found for invoices outside the caller’s account.
What happens after the report
- Day of report
Both reports arrive by email and the certificate is issued.
- Walkthrough
The testers take your developers through every finding live.
- Fixing
We answer your developers’ questions while they fix.
- Fix check
We re-test what you fixed and record it on the certificate.
This sample was written to show the format. Sample Company Pvt Ltd, example.com and all data on this page are fictional.