Phases of a web pentest: from information gathering to the final report

By the QuantumSec team

A web pentest isn't opening Burp Suite and firing random requests. It's a structured process in well-defined phases that follows methodologies like the OWASP Testing Guide, PTES or OSSTMM. Knowing these phases helps you understand what the auditor is doing, what to expect from each stage and how to interpret the final report.

Phase 1: Reconnaissance and information gathering

Before touching the application, the pentester gathers all publicly available information: subdomains, technologies used (Wappalyzer, HTTP headers), SSL certificates, DNS records, exposure on Shodan or Censys, public code repositories, employee accounts on LinkedIn, emails leaked in breaches. This phase is passive and generates no traffic to the target application. The quality of reconnaissance shapes the efficiency of everything that follows.

Phase 2: Enumeration and application mapping

With the recon information, the pentester maps the active attack surface: endpoints, parameters, forms, exposed APIs, authentication functions, session management, user roles. Tools like Burp Suite Pro, ffuf or dirsearch help discover hidden paths, admin panels, undocumented API endpoints and exposed files (.env, backup, .git). The goal is to build a complete map of the application before looking for vulnerabilities.

Phase 3: Vulnerability analysis

Map in hand, the auditor systematically looks for vulnerabilities following the OWASP Top 10 and beyond: injections (SQL, NoSQL, LDAP, OS), broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, XSS, insecure deserialization, use of vulnerable components and insufficient logging. This phase combines automated tools (DAST scanners like Nikto, OWASP ZAP) with manual analysis for the vectors the automated ones miss, especially business logic ones.

Phase 4: Exploitation

In this phase the pentester tries to exploit the vulnerabilities found to demonstrate the real impact. It's not about causing damage, but documenting what an attacker could achieve: extract data from the database, access as another user, bypass authentication, execute code on the server. Each successful exploit is documented with evidence (screenshots, full request/response, payload used). Vulnerabilities that aren't exploitable in the specific environment are marked as not confirmed.

Phase 5: Post-exploitation

Depending on the agreed scope, after compromising a component the auditor assesses what else can be done from that position: access other internal network systems, escalate privileges on the server, access other users' data, read system files, establish persistence. This phase adds the most value in critical applications, because it shows the real chained impact of a single entry point.

Phase 6: Report

The report is the most important deliverable. It must include: an executive summary for management (no technical jargon), a list of findings with severity classification (Critical, High, Medium, Low, Informational), evidence for each finding (screenshots, payloads, requests), an assessment of the real impact (what data or access was obtained), and concrete remediation recommendations for each finding. A good pentest report is actionable: the technical team knows exactly what to change and where to start.

FAQ

How long does a complete web pentest take?

Between 3 and 8 business days for the technical phase, depending on the size and complexity of the application. The report is delivered 2-3 days after the testing ends.

Do I need to stop the application during the pentest?

No. The pentest is done on the production application (or an agreed identical environment) without interrupting the service. The most aggressive tests can be scheduled outside peak hours if you prefer.