Referenzen
Sample Report: Web and API Penetration Testing
This is how technical vulnerabilities become a reliable basis for decisions by management, development and operations.
This work sample is completely synthetic. Organization, systems, people, findings, key figures, requests and times are fictitious. It does not contain any customer or audit data.
Full sample report
The sample report shows an example of how I prepare the results of a web and API penetration test for different target groups. It combines a compact management summary with a comprehensible attack chain, reproducible technical evidence and a prioritized action plan.
The fictitious test object is a B2B contract portal with REST API, three user roles and client-separated business data. The exam does not involve any real systems or data. The example scope is deliberately very limited; In real projects, effort and result format are calculated separately according to scope, role model and coordination requirements.
Management summary
Within the agreed scope of testing, a fictitious B2B web application with an associated API and three user roles was examined. The starting point was an ordinary customer account. The central attack chain was: customer account → SSRF → overprivileged service token → tenant-wide export. It led to a critical overall risk because two findings could be combined:
- A server-side request forgery in the URL import allowed access to an internal administration interface.
- An excessively authorized service token disclosed there allowed cross-client export queries via an externally accessible, token-protected endpoint.
Separately, a missing object-related authorization (BOLA) exposed metadata and documents belonging to another tenant. This independent high finding was not a prerequisite for the critical attack chain.
The detection was completed after a small synthetic sample. A complete data export was not carried out. Based on the scope examined, a complete new development to remedy the documented findings does not appear necessary. The attack chain can be specifically interrupted through secure URL processing and minimally authorized technical identities. The BOLA also requires central client authorization.
Overview of findings
| Risk | Number | Need for decision |
|---|---|---|
| Critical | 1 | Contain it immediately and fix it before the next release |
| High | 2 | Correct in the short term and retest prioritized |
| Medium | 1 | Treat in the next maintenance cycle |
| Low | 1 | Implement with regular curing |
Example finding: Missing object-related authorization
Risk: High
Affected Area: API endpoint for fictitious contract documents
Requirement: Any registered customer account
Impact: A user could access documents from another tenant by changing an object ID. This would violate confidentiality and client separation.
The user interface only showed my own documents. However, the server-side API did not bind the requested object to the session’s tenant. The complete report documents a cleaned example query, the observed response, the expected behavior and the reproducibility.
Recommendation: The access decision must be derived on the server side for each object from the authenticated identity and the permitted tenant mapping. Object and tenant should already be bound in the same database query. In addition, negative tests for object accesses outside of roles and clients are part of the automated test section.
What the full report shows
- Management summary with business impact and release recommendation
- agreed scope, test roles, restrictions and approach
- visualized attack chain from SSRF and overprivileged service token
- Overview of findings with comprehensible risk justification
- cleaned HTTP requests and responses as technical evidence
- concrete measures for development, architecture and operation
- prioritized implementation plan for 24 hours, five working days and several weeks
- clear criteria for a focused retest
- positive observations with identification of the source of evidence and safety controls in place
Prioritized action plan
- Disable or strictly limit URL import until target validation is effective.
- Revoke affected service token, check usage and minimize permissions.
- Correct object-related authorization centrally and check dependent endpoints.
- Add automated negative tests for roles, clients and direct object access.
- Retest corrections in a controlled test environment against the complete attack chain and the independent BOLA finding.
View full sample report in PDF
Your next step
If you need a comparable decision-making basis for your application, tell me the target system, reason and desired period.