Ein Pentest ohne ordentlichen Bericht ist nur halb so viel wert. Der Bericht dokumentiert, was getestet wurde, was gefunden wurde und ob die Behebung funktioniert hat. Für Auditor:innen, die Geschäftsleitung und das Entwicklungsteam ist er gleichermaßen relevant — allerdings aus unterschiedlichen Perspektiven. Die Vorlage weiter unten liefert die Struktur für einen professionellen Bericht mit allen Bestandteilen.
ISO 27001 (A.8.8) verlangt das Management technischer Schwachstellen, A.8.29 fordert Sicherheitstests im Entwicklungsprozess. OWASP WSTG und PTES liefern die methodischen Standards. Unsere Vorlage verbindet alle Perspektiven.
Was die Vorlage abdeckt
Engagement Summary legt die Rahmenbedingungen fest: Wer hat getestet? Was war im Scope? Welche Methodik wurde angewandt? Welcher Testtyp (Black-box, Grey-box, White-box)? Welche Einschränkungen galten (z. B. kein DoS, keine Social-Engineering-Tests)?
Executive Summary fasst die Ergebnisse für die Geschäftsleitung zusammen: Wie viele Findings je Schweregrad? Was war das kritischste Finding? Wie ist die Gesamtbewertung der Sicherheitslage? Dieser Abschnitt ist bewusst kurz und frei von technischen Details.
Findings-Übersicht listet alle Findings in einer Tabelle: ID, Titel, Schweregrad, CVSS-Score und Status. Das gibt einen schnellen Gesamtüberblick.
Detaillierte Findings gehen in die Tiefe. Für jedes Finding: betroffenes Asset, Beschreibung der Schwachstelle, Reproduktionsschritte, Proof of Concept, Schadensausmass und Empfehlung. Die Vorlage enthält drei vollständig ausgearbeitete Beispiele — darunter eine kritische IDOR-Schwachstelle mit CVSS 9.1, eine Stored-XSS-Lücke und ein fehlendes Rate Limiting.
Retest-Ergebnisse dokumentieren, ob die Behebungen tatsächlich wirksam sind. Maßnahmen-Tracking verknüpft offene Findings mit dem Schwachstellenregister und dem Risikobehandlungsplan.
Vorlage: Pentest-Bericht
Dokumentenkontrolle
Eigentümer: Informationssicherheitsbeauftragte
Genehmigt von: CEO
Version: 1.0
Gültig ab: 2026-03-18
Klassifizierung: Vertraulich — beschränkt auf ISMS-Team und Geschäftsleitung
1. Engagement-Zusammenfassung
| Feld | Wert |
|---|---|
| Auftraggeber | Nordwind Logistics GmbH |
| Testanbieter | Cobalt Alliance Security GmbH, Berlin |
| Testleitung | M. Tanaka (OSCP, OSWE) |
| Engagement-ID | PT-2026-01 |
| Scope | Externer Perimeter (4 IPs) + Kundenportal (portal.nordwind-logistics.com) + authentifizierte API |
| Methodik | OWASP WSTG v4.2, PTES, OWASP API Security Top 10 |
| Testzeitraum | 2026-02-24 bis 2026-03-07 |
| Testmodus | Grey-Box (Testkonto + Architektur-Briefing) |
| Rules of Engagement | Kein DoS, kein Social Engineering, Testfenster 07:00–19:00 MEZ |
| Berichtsdatum | 2026-03-10 |
| Retest-Datum | 2026-03-17 |
2. Management Summary
Das Engagement bewertete die externe Angriffsfläche und das kundenseitige Portal, das für ungefähr 450 Kunden die Sendungsverfolgung abwickelt. Die Tester identifizierten 11 Feststellungen: 1 kritisch, 2 hoch, 4 mittel, 3 niedrig und 1 informativ.
Die schwerwiegendste Feststellung ist eine Insecure Direct Object Reference (IDOR) in der Sendungs-API (PT-2026-01-001), die einem authentifizierten Kunden ermöglichte, Sendungsdaten anderer Kunden durch Hochzählen einer internen ID zu lesen. Das Problem war ohne Rate Limiting reproduzierbar und betraf rund 60.000 Datensätze.
Das Gesamt-Sicherheitsniveau ist mittel. Infrastruktur-Hardening und TLS-Konfiguration entsprechen dem Branchenstandard. Die Hauptschwäche liegt in der anwendungsseitigen Autorisierung. Alle kritischen und hohen Feststellungen wurden während des Engagements behoben und im Retest am 2026-03-17 verifiziert.
3. Übersicht der Feststellungen
| ID | Titel | Schweregrad | CVSS | Status |
|---|---|---|---|---|
| PT-2026-01-001 | IDOR in Sendungs-API — horizontaler Zugriff über Kunden hinweg | Kritisch | 9,1 | Behoben |
| PT-2026-01-002 | Stored XSS im Kommentarfeld der Sendung | Hoch | 8,2 | Behoben |
| PT-2026-01-003 | Fehlendes Rate Limit auf Login-Endpunkt | Hoch | 7,5 | Behoben |
| PT-2026-01-004 | Veraltetes jQuery (3.4.1) mit bekannter XSS | Mittel | 6,1 | Behoben |
| PT-2026-01-005 | HTTP-Security-Header unvollständig (kein CSP, kein HSTS-Preload) | Mittel | 5,3 | Behoben |
| PT-2026-01-006 | Verbose Error Messages zeigen Stack-Traces | Mittel | 5,0 | Behoben |
| PT-2026-01-007 | Session-Cookie ohne SameSite-Attribut |
Mittel | 4,8 | Behoben |
| PT-2026-01-008 | Informationsoffenlegung über /api/health-Endpunkt |
Niedrig | 3,1 | Akzeptiert (Risiko dokumentiert) |
| PT-2026-01-009 | TLS 1.1 auf einem Edge-Node noch aktiviert | Niedrig | 3,1 | Behoben |
| PT-2026-01-010 | Benutzername-Enumeration über Passwort-Reset | Niedrig | 3,7 | In Bearbeitung — fällig 2026-04-30 |
| PT-2026-01-011 | Fehlende robots.txt (informativ) |
Info | — | Akzeptiert |
4. Detailfeststellungen (Auszug)
PT-2026-01-001 — IDOR in Sendungs-API
Schweregrad: Kritisch — CVSS 9,1 — CWE-639
Betroffen: GET /api/v1/shipments/{id}
Beschreibung: Die Sendungs-API verwendet fortlaufende Integer-IDs und prüft nicht, ob der authentifizierte Benutzer Eigentümer der angeforderten Sendung ist. Ein Kunde mit gültigem API-Token konnte durch Iteration der IDs beliebige Sendungsdaten anderer Kunden abrufen.
Reproduktion:
- Mit dem Testkonto
testcustomer@cobalt.devauthentifizieren. GET /api/v1/shipments/102834— liefert die eigene Sendung (HTTP 200).GET /api/v1/shipments/102833— liefert die Sendung eines anderen Kunden (HTTP 200) inklusive Empfängername, Adresse und Trackingstatus.
Auswirkung: Vertraulichkeitsverletzung für alle Kunden des Portals. Betroffen sind Namen, Lieferadressen und Sendungsinhaltsbeschreibungen für rund 60.000 Datensätze. Potenzielle Verletzung nach DSGVO Art. 32/33.
Empfehlung:
- Serverseitige Eigentümerprüfung durchsetzen (
shipment.customer_id == current_user.customer_id). - Fortlaufende IDs durch UUIDs für externe Referenzen ersetzen.
- Automatisierten Autorisierungstest in die CI-Pipeline aufnehmen.
Behebung: Eigentümerprüfung am 2026-03-04 ausgerollt. UUID-Migration für Q2 geplant. Im Retest verifiziert — Versuche, fremde Sendungen abzurufen, liefern jetzt HTTP 403.
PT-2026-01-002 — Stored XSS im Kommentarfeld der Sendung
Schweregrad: Hoch — CVSS 8,2 — CWE-79
Betroffen: POST /api/v1/shipments/{id}/comments
Beschreibung: Das Kommentarfeld sanitisierte oder kodierte HTML nicht. Ein Angreifer konnte eine Payload speichern, die im Browser jeder Person ausgeführt wird, die die Sendung ansieht.
Proof of Concept: <img src=x onerror=alert(document.cookie)> wurde gespeichert und beim Ansehen ausgeführt.
Auswirkung: Session-Hijacking von Kundenservice-Mitarbeitenden, die Kommentare ansehen.
Behebung: Output-Encoding über Auto-Escape der Template-Engine. Input-Validierung mit Allowlist. Im Retest verifiziert.
PT-2026-01-003 — Fehlendes Rate Limit auf Login
Schweregrad: Hoch — CVSS 7,5 — CWE-307
Beschreibung: Der Login-Endpunkt akzeptiert unbegrenzte Versuche ohne CAPTCHA oder Sperrung. Der Tester führte 2.000 Anfragen in 60 Sekunden ohne Drosselung durch.
Empfehlung: Rate Limit pro IP und pro Konto. Temporäre Kontosperre nach 10 Fehlversuchen.
Behebung: Rate Limiting (10 Anfragen/min pro IP, 5 Fehlversuche/15 min pro Konto) am 2026-03-06 ausgerollt. Im Retest verifiziert.
(Feststellungen 004–011 folgen derselben Struktur; für diese Vorlage gekürzt.)
5. Außerhalb des Scope / Einschränkungen
- Internes Netzwerk und Active Directory waren nicht im Scope.
- Die Mobile App (iOS + Android) war nicht im Scope.
- Last- und Denial-of-Service-Tests waren ausdrücklich ausgeschlossen.
- Der Test erfolgte während der Geschäftszeiten mit im SIEM sichtbarem Traffic — keine verdeckte Bewertung.
6. Retest-Ergebnisse (2026-03-17)
Cobalt Alliance führte einen Retest für die 10 behobenen Feststellungen durch. Alle retesteten Feststellungen wurden als behoben bestätigt. Feststellung PT-2026-01-010 (Benutzername-Enumeration) war zum Retest noch nicht behoben und bleibt offen mit Fälligkeit 2026-04-30.
7. Maßnahmen und Nachverfolgung
Alle Feststellungen sind im Schwachstellenregister und wo zutreffend im RTP erfasst:
- Offen: PT-2026-01-010 (im Register als VUL-2026-PT01 verfolgt).
- Akzeptiert: PT-2026-01-008, PT-2026-01-011 — akzeptiert durch die ISB mit dokumentierter Begründung.
- Geschlossen: alle übrigen.
8. Fazit
Das Engagement hat seine Ziele erreicht. Die kritische IDOR-Feststellung war die schwerwiegendste und wurde innerhalb des Engagement-Fensters behoben, wodurch eine wahrscheinlich DSGVO-meldepflichtige Offenlegung verhindert wurde. Die Gesamt-Autorisierungslogik des Portals sollte in der nächsten Entwicklungsiteration ganzheitlich überprüft und ein automatisierter Autorisierungstest in die CI-Pipeline aufgenommen werden.
Nächster Pentest: geplant für 2026-Q3 (internes Netzwerk + Active Directory).
Unterschrift: M. Tanaka, Lead Penetration Tester, Cobalt Alliance Security GmbH — 2026-03-10. Zur Kenntnis genommen: Anna Weber, ISB, Nordwind Logistics GmbH — 2026-03-18.
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:
- Authenticate with the test account
testcustomer@cobalt.dev. - Request
GET /api/v1/shipments/102834— returns own shipment (HTTP 200). - 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.
Quellen
- ISO/IEC 27001:2022 Annex A 8.8, A 8.29 — Technisches Schwachstellenmanagement und Sicherheitstests
- OWASP Web Security Testing Guide (WSTG) v4.2 — Methodik für Webanwendungstests
- PTES — Penetration Testing Execution Standard — Rahmenwerk für Penetrationstests