Testing Scope and Objectives
Security testing of web applications requires a systematic approach to identifying and documenting vulnerabilities. The OWASP Web Security Testing Guide establishes methodology in which each discovered defect must be documented with sufficient detail for reproduction and remediation by development teams.
During authorized penetration testing, security professionals must gather evidence of discovered issues. This includes screenshots, request logs, server responses, and other artifacts that confirm the vulnerability existence and help developers understand the problem nature and scope.
- Obtain written authorization before beginning testing activities
- Define the systems and applications in scope
- Establish testing schedule and maintenance windows
Collecting and Documenting Evidence of Vulnerabilities
Each discovered vulnerability must be supported by material evidence. Screenshots should display the specific moment of exploitation: input data provided, results obtained, error messages displayed, or unauthorized data access. Image quality and clarity are critical for stakeholder understanding of the issue.
When capturing screen evidence, ensure proper focus and lighting to avoid blur and distortion. Verify that screenshots include all relevant interface elements, URL bar, request parameters, and server responses. For HTTP-related vulnerabilities, document both the raw request sent and the response received, including headers and message body content.
- Use high resolution for all screenshots and captures
- Include session identifiers and timestamps where relevant
- Document precise reproduction steps for each vulnerability
Classification and Risk Assessment
The OWASP Top 10 provides a standard baseline for the most critical web application security risks. When documenting discovered issues, professionals should classify them against this list or another recognized framework such as CVSS. This enables clients to understand the priority for remediation of each vulnerability.
Severity assessment must consider potential business impact, exploit complexity, and accessibility of the vulnerability. Clearly indicate whether an issue is critical (immediate remediation required), high (short-term fix needed), medium, or low severity based on the application's specific context and data sensitivity.
- Map discovered issues to OWASP Top 10 categories
- Assign severity level with clear justification
- Consider business context in risk assessment
Documenting HTTP Interactions and Network Details
Web application testing frequently requires documenting HTTP protocol specifics. MDN describes HTTP message structure including request methods, headers, parameters, and body content. For each vulnerability, document the exact request and response that demonstrates the issue.
Pay particular attention to security headers—such as missing Content-Security-Policy headers, improper CORS configuration, or authentication bypass mechanisms. Preserve complete traffic logs that can be reproduced using traffic interception tools or command-line utilities for verification and analysis.
- Document HTTP method, path, and request parameters completely
- Include all relevant request and response headers
- Preserve request and response bodies when applicable
Structuring the Testing Report
The penetration test report must be structured for readability by both client management and development teams. Each vulnerability section should contain the issue name, problem description, proof-of-concept screenshots or logs, exact reproduction steps, severity rating, and remediation recommendations.
Maintain consistent formatting across all documented vulnerabilities. Technical teams must quickly understand the problem nature to begin remediation work. Include references to relevant OWASP Web Security Testing Guide sections for additional context and industry-standard guidance.
- Begin with an executive summary of findings and severity distribution
- Provide detailed vulnerability descriptions with supporting evidence
- Conclude with security improvement recommendations
Documentation Workflow During Testing
Effective documentation requires an organized workflow throughout testing activities. Maintain a detailed log of discovered issues, dates found, and actions taken. Use standardized templates or specialized tools to ensure consistent formatting across all recorded findings.
Upon completing each testing phase, verify documentation completeness: are all vulnerabilities recorded, are all supporting files collected, are all reproduction steps documented clearly. This prevents the need for retesting to gather missing information before report submission.
- Maintain a real-time registry of all findings as discovered
- Archive evidence and intermediate results regularly
- Conduct completeness review before testing conclusion
Communicating Results to Stakeholders
Documentation must be tailored for different audiences. Project management requires high-level summary information about risk distribution and timeline impact. Development teams need technical details and exact reproduction steps. Information security leadership requires complete data for trend analysis and process improvement.
Timely and clear communication accelerates vulnerability remediation. Deliver reports in formats agreed with the client (PDF, HTML, specialized tracking systems) and remain available to clarify findings and answer technical questions regarding identified issues.
- Adjust technical detail level for intended audience
- Use client-approved delivery format and schedule
- Provide availability for follow-up questions and clarification