Penetration Test Report: [Client or system name]

Penetration test report. The engagement phases follow the Penetration Testing Execution Standard (PTES), and web application test coverage is organised by the test categories of the OWASP Web Security Testing Guide (WSTG). Replace every [bracketed] value and every finding marked Example. For authorised testing only: never test a system without written permission from its owner.

Document control

Approvals

Distribution

Revision history

Contents

1. Executive summary
2. Scope and rules of engagement
3. Methodology
4. Risk rating method
5. Findings summary
6. Detailed findings
7. Remediation roadmap
8. Retest results
9. Appendices

1. Executive summary

1.1 Overall assessment

Example: Testing of the customer portal between YYYY-MM-DD and YYYY-MM-DD found 1 high, 2 medium and 1 low severity issue. The most serious allows a logged-in customer to view and alter other customers' invoices by changing a number in the address bar, which would expose billing data of all [n] customers. No issue allowed access without an account. Authentication, transport security and session handling were well implemented.

Overall risk rating: [Critical / High / Medium / Low]

1.2 Findings by severity

1.3 Key recommendations

1. Example: Enforce object-level authorisation on every invoice and order endpoint (F-01) before the next release.
2. Example: Encode user content on output across the portal and add a Content Security Policy (F-02).
3. Example: Add rate limiting and lockout monitoring to login (F-03).

1.4 Strengths observed

• [Example: TLS configuration rated strong; HSTS enabled with preload.]
• [Example: Session cookies set with Secure, HttpOnly and SameSite attributes.]

2. Scope and rules of engagement

2.1 Targets in scope

2.2 Out of scope

• [Example: third-party payment provider pages and domains.]
• [Example: denial-of-service and load testing.]
• [Example: social engineering of staff.]

2.3 Rules of engagement

2.4 Limitations

[Example: MFA enrolment flow could not be tested because test accounts were pre-enrolled; API rate limits slowed automated scanning, so coverage of /v2/reports is partial.]

3. Methodology

3.1 Engagement phases (PTES)

3.2 Web application coverage (OWASP WSTG categories)

3.3 Tools used

4. Risk rating method

Findings are scored with the Common Vulnerability Scoring System (CVSS) [v3.1 / v4.0] base metrics, published by FIRST. The base score expresses technical severity; the final rating may be adjusted for business context, and any adjustment is explained in the finding.

Vector formats used:

• CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
• CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Scores are calculated with the official FIRST calculator for the chosen version.

5. Findings summary

6. Detailed findings

F-01: Insecure direct object reference on invoice API

Description. The invoice endpoints check that the caller is logged in but not that the invoice belongs to the caller. Invoice IDs are sequential integers, so any customer can read or modify any other customer's invoice.

Evidence. Logged in as test customer A (cust-a@test), the tester requested invoice 10482, which belongs to test customer B:

GET /v2/invoices/10482 HTTP/1.1
Host: api.example.com
Authorization: Bearer [token for customer A, redacted]

HTTP/1.1 200 OK
{"id":10482,"customerId":"[customer B, redacted]","total":"[redacted]", ...}

A PUT with a changed billing address returned 200 OK and the change was visible to customer B.

Impact. Disclosure and modification of billing names, addresses and amounts for all customers; potential invoice fraud by changing payee references. Exposure affects an estimated [n] records.

Remediation.

1. Enforce object-level authorisation in the invoice service: resolve the invoice through the caller's customer ID, and return 404 when it does not match.
2. Apply the same check to all endpoints that take an object ID (orders, payments, addresses).
3. Add automated tests that call each endpoint with another customer's object ID.
4. Consider non-sequential identifiers as defence in depth, not as the fix.

References. OWASP API Security Top 10, API1 Broken Object Level Authorization; OWASP WSTG Authorization Testing; CWE-639.

F-02: Stored cross-site scripting in support ticket messages

Description. Ticket messages are rendered as HTML without output encoding. A customer can submit markup that runs script in the browser of the support agent who opens the ticket.

Evidence. A message containing <img src=x onerror=alert(document.domain)> triggered an alert showing portal.example.com when opened with the support account. Screenshot: Appendix B, figure 2.

Impact. Script runs in the support agent's session, which can read other customers' tickets. No Content Security Policy limits the effect.

Remediation. Encode output by context in the ticket view (use the framework's default escaping, remove the raw-HTML rendering), sanitise any rich text with an allow-list sanitiser, and deploy a Content Security Policy that forbids inline script.

References. OWASP WSTG Input Validation Testing; OWASP Cross Site Scripting Prevention Cheat Sheet; CWE-79.

F-03: No rate limiting on login

Description. 500 consecutive failed logins for one test account from one IP address were all processed with no delay, lockout or CAPTCHA.

Evidence. Request log excerpt and timing summary in Appendix B, table 3.

Impact. Enables password guessing and credential stuffing against customer accounts.

Remediation. Add per-account and per-IP rate limiting with progressive delays, alert on credential stuffing patterns, and offer MFA to customers.

References. OWASP WSTG Authentication Testing; OWASP Authentication Cheat Sheet; CWE-307.

F-04: Verbose error messages

Description. Malformed request bodies return a stack trace including framework name, version and internal file paths.

Impact. Helps an attacker select exploits for the exact framework version.

Remediation. Return a generic error with a correlation ID; log details server-side only.

References. OWASP WSTG Testing for Error Handling; CWE-209.

7. Remediation roadmap

8. Retest results

9. Appendices

Appendix A: Asset and technology inventory

Appendix B: Evidence index

Appendix C: Test accounts and clean-up

Appendix D: Glossary

Standard and licence note

Based on the engagement phases of the Penetration Testing Execution Standard (PTES, pentest-standard.org); phase names are used as references only. Test categories are taken from the OWASP Web Security Testing Guide (owasp.org/www-project-web-security-testing-guide), copyright the OWASP Foundation, licensed under Creative Commons Attribution-ShareAlike 4.0 (https://creativecommons.org/licenses/by-sa/4.0/); the adapted category structure in section 3.2 is shared under CC BY-SA 4.0. Severity uses CVSS from FIRST (first.org/cvss). Weakness IDs are from MITRE CWE. All other text is original and written for this collection under the MIT licence. This template is for documenting authorised security testing only.