Web Application Pentesting Checklist: OWASP Top 10

A systematic web application penetration test requires more than just running automated scanners. It demands a structured methodology that covers authentication, authorization, injection, business logic, and configuration — the areas where automated tools most often miss critical vulnerabilities. This checklist walks through each phase of a web app pentest aligned with the OWASP Testing Guide and the OWASP Top 10, with specific tools and commands for each step.

Pre-Engagement

Before touching the application, confirm the following:

• Written authorization obtained and signed
• Scope defined — which domains, subdomains, and IP ranges are in scope
• Testing window agreed upon (maintenance windows to avoid)
• Emergency contact established with the client
• Rules of engagement documented (e.g., no DoS testing, no social engineering)
• Testing environment confirmed — production, staging, or isolated lab

Phase 1: Reconnaissance and Information Gathering

Passive Recon (No target interaction)

• WHOIS records — registrar, nameservers, registration date
• DNS records — A, MX, TXT (SPF/DKIM/DMARC), NS, CNAME
• Certificate transparency logs — find all subdomains via crt.sh
• Google dorks — indexed files, admin panels, directory listings
• Shodan/Censys — open ports, server banners without scanning
• Job postings and LinkedIn — tech stack fingerprinting
• GitHub/GitLab searches for leaked credentials or configs

Active Recon

# Subdomain enumeration
ffuf -u https://FUZZ.target.com/ \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  -mc 200,301,302,403

# Directory discovery
ffuf -u https://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt \
  -e .php,.html,.js,.txt,.bak \
  -ac -mc 200,301,302,403,500

# Technology fingerprinting
whatweb https://target.com
wappalyzer https://target.com  # Browser extension or CLI

• Identify web framework, CMS, and server software
• Map all endpoints — forms, API calls, file uploads, login flows
• Note all third-party integrations (analytics, chat widgets, CDNs)

Phase 2: Authentication Testing

A07 — Identification and Authentication Failures

• Default credentials — try admin/admin, admin/password, etc.
• Username enumeration — do error messages differ for valid vs. invalid usernames?
• Password policy — test for minimum length enforcement, complexity
• Brute force protection — is there account lockout after failed attempts?

# Hydra login brute force
hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials"

• Multi-factor authentication — can it be bypassed by manipulating responses?
• Password reset flow — is the token predictable or reusable? Does it expire?
• Remember me functionality — is the persistent token secure and properly invalidated on logout?
• Registration flow — can you register with an existing username or privileged email?

Phase 3: Session Management Testing

• Session token entropy — are tokens random and long enough? (Use Burp Sequencer)
• Session fixation — does the session ID change after login?
• Session timeout — do sessions expire after inactivity?
• Logout functionality — is the session properly invalidated server-side on logout?
• Cookie attributes — check for HttpOnly, Secure, SameSite flags

# Check cookie flags in Burp Suite or curl
curl -v -c cookies.txt https://target.com/login \
  -d "username=admin&password=password"

Phase 4: Authorization Testing

A01 — Broken Access Control

This is the #1 OWASP vulnerability — test it thoroughly.

• Horizontal privilege escalation — can user A access user B’s data by changing an ID?
  • Change ?id=123 to ?id=124, swap GUIDs, alter usernames in parameters
• Vertical privilege escalation — can a regular user access admin functions?
• Forced browsing — access admin paths directly without going through the UI
• IDOR (Insecure Direct Object Reference) — manipulate object identifiers in all parameters

# Example IDOR test in Burp Repeater
GET /api/invoices/1042 → change to /api/invoices/1043
GET /api/users/profile?id=5 → change to id=1 (admin?)

• HTTP method tampering — GET vs. POST vs. PUT vs. DELETE on sensitive endpoints
• JWT manipulation — decode tokens, check for alg:none vulnerability, weak signing secrets

# Decode JWT
echo "eyJ..." | base64 -d

# Test alg:none in jwt_tool
python3 jwt_tool.py <token> -X a

Phase 5: Injection Testing

A03 — Injection

• SQL injection — test all input fields, URL parameters, headers, cookies

sqlmap -u "https://target.com/page?id=1" --dbs --batch
sqlmap -u "https://target.com/login" \
  --data="username=admin&password=test" --dbs

• Command injection — test inputs that might reach OS commands: ;id, |whoami, `id`
• LDAP injection — *)(uid=*))(|(uid=*
• XML/XXE injection — in XML parsers and document upload features
• SSTI (Server-Side Template Injection) — test with {{7*7}}, ${7*7}, <%= 7*7 %>
• NoSQL injection — {"$gt": ""} in MongoDB backends

Phase 6: XSS and Client-Side Testing

A03 — Cross-Site Scripting

• Reflected XSS — inject into search fields, URL parameters, error messages
• Stored XSS — inject into profile fields, comments, usernames, file names
• DOM-based XSS — inspect JavaScript source for unsafe innerHTML, document.write, eval

// Basic XSS payloads to test
<script>alert(1)</script>
"><script>alert(1)</script>
'><img src=x onerror=alert(1)>
javascript:alert(1)

• CSRF (Cross-Site Request Forgery) — are state-changing requests protected by CSRF tokens?
• Clickjacking — is X-Frame-Options or frame-ancestors CSP set?
• Content Security Policy — check Content-Security-Policy header for misconfigurations

Phase 7: Sensitive Data and Cryptography

A02 — Cryptographic Failures

• Is sensitive data transmitted over HTTP instead of HTTPS?
• Are passwords stored as plaintext or weak hashes (MD5, SHA1 without salt)?
• Are API keys, tokens, or credentials exposed in:
  • JavaScript files
  • HTML source comments
  • Error messages
  • HTTP response headers
• Is sensitive data cached by the browser (missing Cache-Control: no-store)?
• Are SSL/TLS configurations strong?

# Test SSL configuration
testssl.sh https://target.com
nmap --script ssl-enum-ciphers -p 443 target.com

Phase 8: Security Misconfiguration

A05 — Security Misconfiguration

• Default or sample files present (/phpinfo.php, /test.php, /.git/, /server-status)
• Verbose error messages exposing stack traces or database names
• Directory listing enabled (Index of /)
• Unnecessary HTTP methods enabled (TRACE, PUT, DELETE)
• Security headers missing or misconfigured:

Header	Expected Value
Strict-Transport-Security	max-age=31536000; includeSubDomains
X-Content-Type-Options	nosniff
X-Frame-Options	DENY or SAMEORIGIN
Content-Security-Policy	Restrictive policy set
Referrer-Policy	strict-origin-when-cross-origin

# Check headers
curl -I https://target.com

Phase 9: Business Logic Testing

Automated scanners completely miss business logic flaws. Manual testing is required:

• Can you skip steps in a multi-step process (e.g., skip payment in a checkout flow)?
• Can quantities or prices be set to negative values?
• Can promo codes be applied multiple times?
• Can you access features reserved for premium accounts?
• Race conditions — two simultaneous requests to consume a resource once?
• Can file uploads bypass type restrictions (rename .php to .php.jpg)?

Phase 10: API Testing

Modern apps have REST or GraphQL APIs that often have weaker security than the UI:

# Discover API endpoints
ffuf -u https://target.com/api/v1/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/api-endpoints.txt

# Test GraphQL introspection
curl -X POST https://target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{__schema{types{name}}}"}'

• Is API versioning properly secured (/api/v1/ vs /api/v2/)?
• Mass assignment vulnerabilities — can you send extra fields to elevate privileges?
• Rate limiting on authentication endpoints?
• Are verbose error responses returned from APIs?

Reporting Checklist

Every finding should include:

• Vulnerability name and CVSS score
• Description — what is the vulnerability?
• Evidence — screenshots, HTTP request/response, PoC code
• Impact — what could an attacker achieve?
• Remediation — specific, actionable fix recommendation
• References — OWASP link, CVE if applicable

Severity tiers: Critical → High → Medium → Low → Informational

Recommended Tool Stack

Phase	Tools
Proxy/Manual Testing	Burp Suite Pro or Community
Directory Fuzzing	ffuf, gobuster
Vuln Scanning	Nikto, OWASP ZAP
SQL Injection	sqlmap
Subdomain Enum	subfinder, amass, ffuf
SSL Testing	testssl.sh
JS Analysis	LinkFinder, JSParser

Summary

A thorough web application pentest is a methodical process — not a tool dump. Work through each OWASP category systematically, document every finding with evidence, and always test business logic manually. The combination of automated discovery and manual analysis is what separates a useful pentest report from a glorified Nikto scan. Always work within your authorized scope and adhere to the rules of engagement.