Web App Pentest Report Guide
Web application penetration tests produce more findings in more categories than almost any other engagement type. The report has to organize all of that clearly without becoming a 50-page document nobody reads past page 3.
Here is how to structure a web application pentest report that actually gets used.
What Makes Web App Reports Different
Network pentest reports are mostly about configuration. Outdated software, exposed services, weak credentials. The findings are relatively uniform.
Web application reports cover a much wider surface. Authentication flaws, business logic bypasses, injection vulnerabilities, access control failures, API weaknesses, client-side issues. Each category needs different evidence and different remediation guidance.
The other difference is the audience. Web app findings directly affect developers. Your report needs to be specific enough that a developer can open it, find the relevant finding, and know exactly what to fix and where.
Core Sections for Web App Reports
Scope
Every URL, subdomain, API endpoint, and authenticated role that was in scope. Be specific. “The web application at app.company.com including all authenticated user roles and the /api/v1/ endpoint group.” Scope ambiguity creates liability when something is found post-engagement.
Authentication testing summary
How you tested authentication. Password policy, account lockout, session management, MFA implementation, password reset flow. This deserves its own section because authentication flaws are often the most critical findings and clients want to see it was tested thoroughly.
Findings by OWASP category
Organizing by OWASP Top 10 category makes the report more useful for development teams who are already familiar with the taxonomy. Injection, Broken Access Control, Security Misconfiguration, and so on. Findings sorted by severity within each category.
API testing section
If the application has an API, document your testing methodology separately. REST, GraphQL, and SOAP each have different attack surfaces. Clients building API-heavy applications want to see this coverage explicitly.
Business logic testing
The hardest section to write and the most valuable. Document what business logic you tested and what you found. A price manipulation bypass or a workflow sequence exploit is often more impactful than a technical vulnerability but harder to explain clearly. Take the time to write this section well.
How to Document Web Findings
Each finding needs five things to be actionable.
The exact request and response. Not a screenshot of Burp. The actual HTTP request that triggers the vulnerability and the response that proves it. Copy-paste formatted, not an image.
The affected parameter or function. Not just the URL. The specific input field, header, parameter name, or code path where the vulnerability exists.
The reproduction steps. Numbered, from a fresh browser session. Include any preconditions like “logged in as a standard user account.” A developer reproducing this should not have to ask you any questions.
The impact in application context. Not the OWASP definition of IDOR. What data from their specific application was accessible, what actions were possible, which user roles were affected.
A specific fix. For injection vulnerabilities, name the parameterized query or ORM method. For access control failures, describe the specific authorization check that is missing. For session issues, cite the specific cookie attribute or token handling change needed.
Evidence Standards
Screenshots are the minimum. For any finding above low severity, include the raw HTTP request and response from Burp or your proxy of choice. Format it as a code block in the report, not an image. It is searchable, copyable, and more credible.
For business logic findings, a short screen recording is often clearer than 10 screenshots. Reference it in the finding and include it as an appendix.
For blind vulnerabilities like SSRF or blind XSS, show your callback server receiving the connection. A Burp Collaborator interaction or an Interactsh hit with the relevant payload is your proof of concept.
Generating Web App Reports Without Starting From Scratch
A thorough web application report for a medium-complexity application takes 4-7 hours to write manually. Formatting HTTP requests, calculating CVSS scores per finding, writing the executive summary, structuring the OWASP sections.
PentestReportAI handles the structural and formatting work. Paste in your findings and tool outputs, and it outputs a structured report with CVSS 3.1 scores, executive summary, technical findings table, and remediation recommendations. There is a dedicated OWASP Top 10 template for web application engagements.
Your testing data never leaves your machine
The desktop app runs entirely locally. Your HTTP requests, exploit payloads, and client application details stay on your device.