Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Starter Kit · Plans & Reports

Penetration Test Report

Updated on 2 min Reviewed by: Cenedril Editorial
A.8.8A.8.29 ISO 27001OWASP WSTGPTES

A pentest without a proper report is only half as valuable. The report documents what was tested, what was found and whether the remediation worked. Auditors, top management and the development team all need it — each from a different perspective. The template below provides the structure for a professional report with all components.

ISO 27001 (A.8.8) requires the management of technical vulnerabilities, A.8.29 requires security testing in the development process. OWASP WSTG and PTES provide the methodological standards. Our template brings all perspectives together.

What the template covers

Engagement summary establishes the parameters: who tested, what was in scope, which methodology was applied, which test type (black-box, grey-box, white-box) and what limitations applied (e.g. no DoS, no social engineering).

Executive summary condenses the results for top management: how many findings by severity, what was the most critical finding, what is the overall security posture? This section is deliberately short and free of technical detail.

Findings overview lists all findings in a table: ID, title, severity, CVSS score and status. This gives a quick overall picture.

Detailed findings go deep. For each finding: affected asset, vulnerability description, reproduction steps, proof of concept, impact and recommendation. The template includes three fully worked examples — including a critical IDOR vulnerability with CVSS 9.1, a stored XSS and missing rate limiting.

Retest results document whether remediations are actually effective. Remediation tracking links open findings to the vulnerability register and the risk treatment plan.

Template: Penetration Test Report

Full policy text

Penetration Test Report

.md · EN.md · DE

Document control
Owner: Information Security Officer
Approved by: CEO
Version: 1.0
Effective date: 2026-03-18
Classification: Confidential — restricted to ISMS team and top management

1. Engagement summary

Field Value
Client Nordwind Logistics GmbH
Test provider Cobalt Alliance Security GmbH, Berlin
Test lead M. Tanaka (OSCP, OSWE)
Engagement ID PT-2026-01
Scope External perimeter (4 IPs) + customer portal (portal.nordwind-logistics.com) + authenticated API
Methodology OWASP WSTG v4.2, PTES, OWASP API Security Top 10
Test dates 2026-02-24 to 2026-03-07
Testing type Grey-box (test account + architecture briefing)
Rules of engagement No DoS, no social engineering, testing windows 07:00–19:00 CET
Report date 2026-03-10
Retest date 2026-03-17

2. Executive summary

The engagement assessed the external attack surface and the customer-facing portal that handles shipment tracking for approximately 450 customers. The tester identified 11 findings: 1 critical, 2 high, 4 medium, 3 low, and 1 informational.

The most severe finding is an Insecure Direct Object Reference (IDOR) in the shipment API (PT-2026-01-001), which allowed an authenticated customer to read shipment records of other customers by incrementing an internal ID. The issue was reproducible without rate limiting and affected approximately 60,000 records.

Overall security posture is moderate. Infrastructure hardening and TLS configuration are in line with industry practice. Application-layer authorisation is the main weakness. All critical and high findings were remediated during the engagement and verified in the retest on 2026-03-17.

3. Findings overview

ID Title Severity CVSS Status
PT-2026-01-001 IDOR in shipment API — horizontal access across customers Critical 9.1 Remediated
PT-2026-01-002 Stored XSS in shipment comment field High 8.2 Remediated
PT-2026-01-003 Missing rate limit on login endpoint High 7.5 Remediated
PT-2026-01-004 Outdated jQuery (3.4.1) with known XSS Medium 6.1 Remediated
PT-2026-01-005 HTTP security headers incomplete (no CSP, no HSTS preload) Medium 5.3 Remediated
PT-2026-01-006 Verbose error messages reveal stack traces Medium 5.0 Remediated
PT-2026-01-007 Session cookie without SameSite attribute Medium 4.8 Remediated
PT-2026-01-008 Information disclosure via /api/health endpoint Low 3.1 Accepted (risk documented)
PT-2026-01-009 TLS 1.1 still enabled on one edge node Low 3.1 Remediated
PT-2026-01-010 Username enumeration via password reset Low 3.7 In progress — due 2026-04-30
PT-2026-01-011 Missing robots.txt (informational) Info — Accepted

4. Detailed findings (excerpt)

PT-2026-01-001 — IDOR in shipment API

Severity: Critical — CVSS 9.1 — CWE-639

Affected: GET /api/v1/shipments/{id}

Description: The shipment API uses sequential integer IDs and does not verify that the authenticated user is the owner of the requested shipment. A customer with a valid API token could retrieve any other customer's shipment data by iterating IDs.

Reproduction:

  1. Authenticate with the test account testcustomer@cobalt.dev.
  2. Request GET /api/v1/shipments/102834 — returns own shipment (HTTP 200).
  3. Request GET /api/v1/shipments/102833 — returns shipment belonging to another customer (HTTP 200), including recipient name, address, and tracking status.

Impact: Confidentiality breach affecting all customers of the portal. Data exposure includes names, delivery addresses, and shipment content descriptions for approximately 60,000 records. Potential GDPR Art. 32/33 breach.

Recommendation:

  • Enforce server-side ownership check (shipment.customer_id == current_user.customer_id).
  • Replace sequential IDs with UUIDs for external references.
  • Add an automated authorisation test to the CI pipeline.

Remediation: Ownership check deployed on 2026-03-04. UUID migration scheduled for Q2. Verified in retest — attempts to read other customers' shipments now return HTTP 403.

PT-2026-01-002 — Stored XSS in shipment comment field

Severity: High — CVSS 8.2 — CWE-79

Affected: POST /api/v1/shipments/{id}/comments

Description: The comment field did not sanitise or encode HTML. An attacker could store a payload that executes in the browser of any user viewing the shipment.

Proof of concept: <img src=x onerror=alert(document.cookie)> was stored and executed on view.

Impact: Session hijacking of customer service staff viewing comments.

Remediation: Output encoding via the templating engine's auto-escape. Input validation with allowlist. Verified in retest.

PT-2026-01-003 — Missing rate limit on login

Severity: High — CVSS 7.5 — CWE-307

Description: The login endpoint accepts unlimited attempts without CAPTCHA or lockout. Tester performed 2,000 requests in 60 seconds without throttling.

Recommendation: Rate limit per IP and per account. Temporary account lockout after 10 failed attempts.

Remediation: Rate limiting (10 req/min per IP, 5 failed/15 min per account) deployed on 2026-03-06. Verified in retest.

(Findings 004–011 follow the same structure; abbreviated for this template.)

5. Out of scope / limitations

  • Internal network and Active Directory were not in scope.
  • The mobile app (iOS + Android) was not in scope.
  • Load and denial of service tests were explicitly excluded.
  • The test was performed during business hours with traffic visible in SIEM — not a stealth assessment.

6. Retest results (2026-03-17)

Cobalt Alliance performed a retest covering the 10 remediated findings. All retested findings were confirmed as remediated. Finding PT-2026-01-010 (username enumeration) was not yet fixed at retest and remains open with a due date of 2026-04-30.

7. Actions and tracking

All findings have been entered into the vulnerability register and the RTP where applicable:

  • Open: PT-2026-01-010 (tracked as VUL-2026-PT01 in the register).
  • Accepted: PT-2026-01-008, PT-2026-01-011 — accepted by the ISO with documented rationale.
  • Closed: all others.

8. Conclusion

The engagement achieved its objectives. The critical IDOR finding was the most significant and was remediated within the engagement window, preventing a likely GDPR-reportable exposure. The portal's overall authorisation logic should be reviewed holistically in the next development iteration, and an automated authorisation test added to the CI pipeline.

Next pentest: scheduled for 2026-Q3 (internal network + Active Directory).

Signed: M. Tanaka, Lead Penetration Tester, Cobalt Alliance Security GmbH — 2026-03-10. Acknowledged: Anna Weber, ISO, Nordwind Logistics GmbH — 2026-03-18.

Sources

ISO 27001 Controls Covered

A.8.8 Management of technical vulnerabilities A.8.29 Security testing in development and acceptance

Frequently asked questions

How often must a pentest be performed?

ISO 27001 does not prescribe a fixed frequency, but A.8.8 expects technical vulnerability assessments. In practice an annual rhythm works well, supplemented by event-driven tests after major changes. Most certification bodies expect at least one pentest per year.

What belongs in a professional pentest report?

Engagement summary (scope, methodology, test dates), executive summary for top management, findings overview with severity and status, detailed descriptions with reproduction steps, retest results and an actions table. Our template covers all parts.

Who should receive the report?

The report is confidential. It goes to the ISO, top management and the development team (where relevant). Auditors expect access to the report and evidence that findings have been tracked.

What happens with findings that cannot be fixed immediately?

They are recorded in the vulnerability register, assigned an SLA and tracked. The template includes a status column (Remediated, In Progress, Accepted) and a link to the risk treatment plan for accepted risks.