- Home
- Penetration testing
- Sample report
An anonymised grey-box pentest report
Marked up page by page, so you see exactly what you get.
Confidential
Penetration Testing Report
Prepared for · Grey-box web application & infrastructure
Confidential — do not distributeBranded, confidential and reference-numbered. Compliance files it as audit evidence; sales forwards it to a customer’s security team under NDA.
The cover states what we tested, the window and who tested it. No scope dispute at sign-off, and your auditor reads the boundary at a glance.
Contents
- 1Executive summary & security grade
- 2Scope & assets
- 3Summary of findings & business risk
- 4OWASP coverage
- 5Methodology & tools
- 6Reconnaissance
- 7Findings in detail
- 8Remediation retest
- 9Letter of attestation
- AAppendix: OWASP WSTG checklist
Ordered from the board summary to the technical appendix, so a CISO reads the front and an engineer jumps to the findings.
Executive summary
The test found a path from an unauthenticated internet user to full server control, plus weaknesses that expose customer data and user accounts. The recommendations run in priority order.
Grading criteria
| Grade | Level | What it means |
|---|---|---|
| A | Excellent | Exceeds industry best practice; a few low-risk findings. |
| B | Good | Meets best practice; a handful of medium and low issues. |
| C | Fair | Some areas protected; moderate changes needed. |
| D | Poor | Significant deficiencies; immediate attention needed. |
| F | Inadequate | Serious deficiencies across most controls. |
A security grade, benchmarked A to F, on the first page. Your board acts on one letter; the evidence sits behind it.
The grade maps to a published scale, so it reads the same next quarter and against other vendors, and it moves once you remediate.
Scope & assets
We tested a staging copy of the application. Everything below was agreed before testing started.
| In scope | Type |
|---|---|
| app. | Web application |
| api. | REST API |
| /24 | External network range |
| 3 user roles | Admin, staff, customer |
Out of scope: production systems, third-party payment provider, physical and social engineering.
Every host, app, user role and IP range we covered, and what we left out. Your team confirms coverage; procurement confirms it matches the statement of work.
Summary of findings
| Severity | Critical | High | Medium | Low | Info |
|---|---|---|---|---|---|
| Findings | 1 | 2 | 3 | 5 | 1 |
Summary of business risk
- A single upload flaw lets an attacker run commands on the server, a company-wide ransomware and data-breach risk.
- Account takeover through stored scripting damages customer trust and triggers breach-notification duties.
- Exposed service versions and weak lockout make brute-force and targeted exploitation easier.
High-level recommendations
- Validate and sandbox file uploads; store them outside the web root.
- Enforce output encoding and a content-security policy to close scripting paths.
- Add rate limiting and account lockout; patch exposed components.
Severity counts up top. You size the problem and brief leadership before anyone opens a technical page.
Each finding stated as a business outcome: a reportable breach, downtime, a lost enterprise deal. The number earns its budget.
A remediation list ordered by impact, so your engineers spend the first sprint on what an attacker reaches first.
OWASP coverage
Tested against the OWASP Web Security Testing Guide. Each item maps to the standards you report on.
| OWASP Top 10 | Status |
|---|---|
| A01 Broken access control | Fails |
| A02 Cryptographic failures | Fails |
| A03 Injection | Fails |
| A04 Insecure design | Meets |
| A05 Security misconfiguration | Fails |
| A06 Vulnerable components | Fails |
| A07 Authentication failures | Meets |
| A08 Integrity failures | Meets |
| A09 Logging & monitoring | Fails |
| A10 Server-side request forgery | Fails |
Pass or fail per OWASP category, and each finding tagged to PCI DSS, ISO 27001, SOC 2, NIS2 or DORA. It drops into your audit evidence with no translation step.
Methodology & tools
We name the standards we follow and the tools we use, so the report holds up with any auditor.
Standards
- Penetration Testing Execution Standard (PTES)
- OWASP Web Security Testing Guide & API Security Top 10
- NIST SP 800-115, OSSTMM, MITRE ATT&CK
Tooling & manual testing
Burp Suite Pro, Nmap, Nessus, Nuclei, ffuf, BloodHound and custom tooling for coverage. Then manual testing for the findings scanners miss, and a hand-check on every automated hit.
We name the standards the test followed, PTES and the OWASP WSTG. Your security lead judges the depth; your auditor accepts it.
We run the tooling, then confirm every hit by hand. Your engineers keep their sprint instead of triaging scanner false positives.
Reconnaissance
What an attacker sees before touching anything. Mapped first, so nothing exposed stays off the test.
Open ports
| Host | Port | Service |
|---|---|---|
| vpn. | 4433/tcp | SSL-VPN portal |
| mail. | 443/tcp | Webmail |
| 8080/tcp | Exposed admin console |
Subdomains
7 discovered, 2 live. One forgotten staging host served an old, unpatched build.
Open ports, live subdomains and forgotten hosts, mapped before exploitation. Teams often find assets here they had dropped from the inventory.
Finding WEB-01 — Critical
| Severity Critical | CVSS 3.1 9.8 (AV:N/AC:L) | OWASP A03 Injection |
Malicious file upload leads to remote command execution
The avatar upload endpoint accepts a server-side script, which can then be requested directly, running attacker commands as root.
Proof of concept
GET /uploads/shell.php?c=id → uid=0(root) gid=0(root)
Business impact
An unauthenticated attacker runs commands as root: read or encrypt every customer record, pivot to internal systems, and take the platform offline.
Remediation
- Validate upload type server-side against an allow-list; reject executables.
- Store uploads outside the web root and serve them through a handler.
- Run uploads through anti-malware; rotate the exposed credentials.
Retest: Fixed. Re-tested after remediation and confirmed closed.
Severity plus a CVSS 3.1 vector on every finding. Your engineers rank the backlog; you defend the priority to the board with a number.
The exact request and response. Your engineers replay it, get the same result, and skip the argument over whether it is real.
What the attacker reaches, in plain terms: customer records, encrypted systems, downtime. The line a non-technical exec acts on.
Remediation steps that name the exact control, like allow-listing upload types. Specific enough to assign and close.
You remediate, we re-test and mark each item closed. The report holds the finding, the fix and the proof it worked.
Finding WEB-02 — High
| Severity High | CVSS 3.1 8.1 | OWASP A10 SSRF |
Server-side request forgery reaches the cloud metadata service
The link-preview feature fetches any URL the user supplies. We pointed it at the cloud metadata endpoint and read temporary credentials for the hosting account.
→ AccessKeyId:
Retest: Fixed. Allow-list and metadata block confirmed in place.
We chain the finding to what it unlocks: internal services and cloud credentials an outsider should not reach. The severity reflects the reach, which a raw CVE score misses.
Finding WEB-04 — Medium
| Severity Medium | CVSS 3.1 6.5 | OWASP A01 Access control |
Broken access control exposes other customers’ invoices
Changing the invoice ID in the URL returned another customer’s billing data. A standard user read records across the whole tenant base.
Retest: Fixed. Server-side ownership checks added on every object.
Severity, proof and a named fix for each issue down the list. The mediums carry the detail that turns into next quarter’s critical.
Remediation retest
| Finding | Severity | Status |
|---|---|---|
| WEB-01 Remote command execution | Critical | Fixed |
| WEB-02 Server-side request forgery | High | Fixed |
| WEB-03 Stored cross-site scripting | High | Fixed |
| WEB-04 Broken access control | Medium | Fixed |
| WEB-08 Missing security headers | Info | Open |
The retest re-grades you from C to A and documents it. You show the board a result for the spend, and the retest is in the price.
A line-by-line status after your fixes. Your auditor and your customers see what we found and that you closed it.
Letter of attestation
This letter attests that Q-SEC performed a grey-box web application and infrastructure penetration test for during the stated period, followed by a remediation retest.
At retest, all critical, high, medium and low findings were verified as remediated. The security posture was re-graded from C (Fair) to A (Excellent).
Testing followed PTES and the OWASP Web Security Testing Guide, performed by EU-based penetration testers.
Q-SEC — Penetration Testing
Signed, dated and reference-numbered · QS-PT-0417
A one-page signed letter for a customer’s security team, an auditor or a cyber-insurer, without exposing the full report. It states the before and after grade.
Appendix A — OWASP WSTG checklist
Every test case, marked tested or not applicable. A sample of the full appendix below.
| Category | Test | Result |
|---|---|---|
| Authentication | Credentials over encrypted channel | Fail |
| Authentication | Account lockout mechanism | Fail |
| Session | Session token after logout | Pass |
| Input | Stored cross-site scripting | Fail |
| Authorization | Insecure direct object reference | Fail |
| Config | Security headers present | Fail |
Every OWASP test case, marked tested or not applicable. Your security lead sees the coverage end to end, with no gaps glossed over.
See your own report
Scope a test and get a fixed quote. Want the full sample report as a PDF? Ask in the form and we’ll send it.
.webp)
A few details and we’ll send a fixed price. We reply within 1 business day.
Pixel icons by Streamline, CC BY 4.0.