Web Application Penetration Testing - A Complete Methodology Guide

Web application penetration testing is the practice of systematically testing a web application for security vulnerabilities by simulating the techniques an attacker would use. Unlike automated vulnerability scanning, a proper web app pentest involves manual analysis, creative attack chaining, and business logic testing that scanners cannot replicate.

This guide walks through a complete web application penetration testing methodology from initial reconnaissance through reporting, with specific tools and techniques for each phase.

Phase 1: Reconnaissance and Information Gathering

Before touching the application, gather as much information as possible about the target. This phase is about understanding the attack surface.

Passive Reconnaissance:

• WHOIS lookups and DNS enumeration to identify related domains and subdomains
• Google dorking for exposed files, admin panels, and error messages: site:target.com filetype:sql, site:target.com inurl:admin
• Search for the target on GitHub, Pastebin, and other code-sharing platforms for leaked credentials or configuration files
• Review the Wayback Machine for historical versions of the application that may reveal removed functionality

Active Reconnaissance:

• Subdomain enumeration using tools like Sublist3r, Amass, or subfinder
• Port scanning with Nmap to identify all services: nmap -sV -sC -p- target.com
• Technology fingerprinting with Wappalyzer, WhatWeb, or Builtwith to identify the tech stack
• Directory and file brute forcing with Gobuster or ffuf: gobuster dir -u https://target.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Mapping the Application:

Use Burp Suite to spider the application. Browse every page, click every link, submit every form. Build a complete site map. Pay attention to:

• All input fields (GET parameters, POST bodies, headers, cookies)
• Authentication and session management mechanisms
• File upload functionality
• API endpoints
• JavaScript files that may reveal hidden endpoints

Phase 2: Vulnerability Discovery

With the application mapped, systematically test each input point and functionality area for common vulnerability classes.

SQL Injection (SQLi)

Test every parameter that interacts with a database. Start with simple payloads and escalate:

' OR 1=1--
' UNION SELECT NULL,NULL,NULL--
' AND SLEEP(5)--

Tools: Burp Suite Intruder for manual testing, sqlmap for automated exploitation:

sqlmap -u "https://target.com/search?q=test" --dbs --batch

Look for error-based, union-based, blind boolean, and time-based injection. Test not just obvious search fields but also cookies, headers (User-Agent, Referer, X-Forwarded-For), and JSON/XML request bodies.

Cross-Site Scripting (XSS)

Test for reflected, stored, and DOM-based XSS. Inject payloads into every input field and observe where the input is rendered:

<script>alert(1)</script>
"><img src=x onerror=alert(1)>
javascript:alert(1)

If basic payloads are filtered, try bypasses:

<svg/onload=alert(1)>
<details open ontoggle=alert(1)>
<img src=x onerror=alert&#40;1&#41;>

Use Burp Suite's scanner for automated detection, but always verify manually. DOM XSS requires JavaScript source analysis - look for dangerous sinks like innerHTML, document.write, and eval being fed user-controlled data.

Cross-Site Request Forgery (CSRF)

Check if state-changing requests (password changes, email updates, fund transfers) include anti-CSRF tokens. If they do, test whether the token is actually validated:

• Remove the token entirely
• Use a token from a different session
• Change the token value
• Check if the token is tied to the session

If any of these work, the CSRF protection is ineffective.

Insecure Direct Object References (IDOR)

IDOR vulnerabilities exist when the application uses user-supplied identifiers to access objects without proper authorization checks. Test by:

1. Logging in as User A
2. Noting the identifiers used in requests (user IDs, order IDs, document IDs)
3. Changing those identifiers to values belonging to User B
4. Checking if User A can access User B's data

This applies to REST API endpoints, file download URLs, profile pages, and any request containing a sequential or predictable identifier.

Authentication and Session Testing

• Test for weak password policies and brute force protection
• Check session token entropy and predictability
• Test for session fixation (can you set a session cookie before login?)
• Verify that logout actually invalidates the session server-side
• Test password reset flows for token predictability and account enumeration
• Check for username enumeration through different error messages

File Upload Vulnerabilities

If the application accepts file uploads:

• Try uploading a web shell (.php, .asp, .jsp) and accessing it directly
• Test content-type bypass: change the Content-Type header while keeping a malicious extension
• Try double extensions: shell.php.jpg
• Test null byte injection: shell.php%00.jpg (older systems)
• Check if uploaded files are served from the same domain (enables XSS via SVG or HTML uploads)

Server-Side Request Forgery (SSRF)

Any functionality that fetches external URLs (URL preview, webhook configuration, PDF generation) is a potential SSRF vector. Test with:

• Internal IP ranges: http://127.0.0.1, http://169.254.169.254 (cloud metadata)
• DNS rebinding
• Protocol smuggling: gopher://, file://

Phase 3: Exploitation

Once vulnerabilities are identified, demonstrate their impact. The goal is not to cause damage but to prove the severity:

• SQL injection: extract sensitive data (password hashes, PII, API keys), demonstrate potential for data modification
• XSS: show cookie theft, session hijacking, or phishing overlay as proof of concept
• IDOR: demonstrate unauthorized access to other users' data
• SSRF: access internal services, retrieve cloud metadata credentials

Use OWASP ZAP alongside Burp Suite for a second opinion on findings. ZAP's active scanner catches things Burp's might miss and vice versa.

Chain vulnerabilities where possible. An IDOR that leaks email addresses combined with a password reset flaw might result in full account takeover. A low-severity XSS on a subdomain combined with shared cookie scope might escalate to session hijacking on the main application.

Phase 4: Reporting

A penetration test is only as good as its report. Structure your findings clearly:

Executive Summary: Non-technical overview of the test scope, methodology, and key findings. Written for management.

Technical Findings: Each vulnerability documented with:

• Title and severity rating (CVSS score)
• Affected URL/parameter
• Description of the vulnerability
• Step-by-step reproduction instructions
• Screenshots or HTTP request/response pairs as evidence
• Impact assessment (what an attacker could achieve)
• Remediation recommendation with specific code or configuration changes

Methodology Section: What was tested, tools used, time spent. This helps the client understand the coverage.

Risk Ratings: Use a consistent framework. CVSS 3.1 is the industry standard. Always explain why you assigned a particular severity - context matters.

Essential Tools

Common Mistakes to Avoid

Not testing business logic. Scanners find injection flaws. They do not find logic flaws like being able to apply a discount code twice, skip payment steps, or modify order quantities to negative values. Manual testing of business workflows is critical.

Ignoring the JavaScript. Modern web applications are heavily client-side. API endpoints, hidden functionality, hardcoded credentials, and debug modes are often discoverable by reading the JavaScript bundles. Use browser developer tools and source map files when available.

Reporting without proof. Every finding needs reproduction steps and evidence. "The application may be vulnerable to XSS" is not a finding. "The search parameter at /products?q= reflects unescaped input, allowing JavaScript execution (screenshot attached)" is a finding.

Skipping low-severity issues. Report everything you find. A low-severity information disclosure combined with another low-severity issue might chain into a high-severity attack. Let the client decide what to fix.

Web application penetration testing is a skill that improves with practice. Set up deliberately vulnerable applications like DVWA, WebGoat, and Juice Shop. Practice the methodology on those targets until it becomes second nature. Then apply it to real engagements.