Web Application Pentesting Checklist: A Practical Methodology for Bug Bounty Hunters

A structured web application pentesting methodology can make the difference between randomly testing endpoints and systematically discovering security vulnerabilities.

This guide presents an original, practical checklist covering reconnaissance, authentication, session management, input validation, business logic, infrastructure, and security controls.

Disclaimer:_ Only test applications and infrastructure that you own or have explicit authorization to assess._

1. Reconnaissance

Before testing vulnerabilities, understand the target.

1.1 Define the Scope

Classify the target:

Large scope — multiple domains, organizations, or IP ranges
Medium scope — one primary domain with multiple subdomains
Small scope — a specific website or application

1.2 Large-Scope Recon

For larger organizations:

Identify ASN and associated IP ranges
Search for additional organizational domains
Review acquisitions and subsidiaries
Identify relationships between domains and organizations
Map discovered domains back into individual reconnaissance workflows

1.3 Domain and Subdomain Enumeration

Build a complete asset inventory.

Check:

Passive subdomain enumeration
Active enumeration
DNS brute forcing
Subdomain permutations
Recursive subdomain discovery
Historical subdomains
Certificate transparency data
Cloud-hosted assets

Useful tools include:

subfinder
amass
puredns
httpx
dnsx

1.4 Identify Live Hosts

Probe discovered hosts and record:

HTTP/HTTPS status
Redirects
Web technologies
Server headers
Page titles
Content length
TLS information

Take screenshots of interesting hosts so that the attack surface can be reviewed quickly later.

2. Web Application Discovery

Once live hosts are identified, start mapping the application.

Files and Endpoints Worth Checking

Look for commonly exposed resources such as:

/robots.txt
/sitemap.xml
/.well-known/
/crossdomain.xml
/clientaccesspolicy.xml

/robots.txt
/sitemap.xml
/.well-known/
/crossdomain.xml
/clientaccesspolicy.xml

Also investigate:

Backup files
Configuration files
Debug endpoints
Development endpoints
Documentation
API specifications
Forgotten administrative interfaces

Directory and File Discovery

Perform content discovery against authorized targets.

Look for:

Hidden directories
Old application versions
Backup files
Temporary files
Administrative panels
API endpoints
Configuration files

Tools commonly used:

ffuf
feroxbuster
dirsearch

3. Technology Fingerprinting

Determine what the application is built with.

Identify:

Web server
Programming language
Framework
CMS
JavaScript framework
Database technology
CDN
WAF
Authentication technology
Cloud provider

Technology fingerprinting helps prioritize testing because different technologies expose different classes of vulnerabilities.

4. URL and Parameter Discovery

Build a large URL collection from:

Current application crawling
Historical URLs
Public archives
JavaScript files
API documentation
Robots and sitemap files
Search-engine results

Useful tools include:

gau
waybackurls
gospider
katana

Then normalize and deduplicate the results.

Pay particular attention to URLs containing parameters such as:

?id=
?user=
?file=
?url=
?redirect=
?next=
?return=
?path=
?query=
?search=

?id=
?user=
?file=
?url=
?redirect=
?next=
?return=
?path=
?query=
?search=

These parameters often represent valuable testing points.

5. JavaScript Analysis

Modern applications frequently expose a large amount of useful information through JavaScript.

First collect JavaScript files.

Then inspect them for:

API endpoints
Internal routes
Hidden functionality
Feature flags
Environment names
Debug information
Third-party integrations
Hardcoded credentials
API keys
Internal hostnames

Useful tools include:

subjs
xnLinkFinder
LinkFinder
nuclei

Manual review is still important because automated tools can miss application-specific logic.

6. Authentication Testing

Authentication is one of the most important areas of a web application assessment.

Registration

Test:

Duplicate account creation
Username uniqueness
Email verification
Disposable email restrictions
Weak password requirements
Account takeover possibilities
Registration rate limiting
OAuth registration
Social login integration
Redirect behavior after registration
Input validation
Stored XSS in registration fields

Also test unusual but harmless variations of registration inputs to understand how the application normalizes identities.

Check:

Username enumeration
Password guessing resistance
Account lockout
Rate limiting
MFA enforcement
Authentication bypass
OAuth implementation
SAML implementation
Login redirects
Session creation
Remember-me functionality
Password policy
Transport security

Where multiple authentication mechanisms exist, compare their behavior carefully.

8. Multi-Factor Authentication

Review:

OTP generation
OTP expiration
OTP reuse
Rate limiting
Verification logic
Recovery mechanisms
MFA reset functionality
Response manipulation
Session behavior after MFA changes

Always focus on the application's authorization logic rather than merely trying large numbers of guesses.

9. Password Reset

Password recovery is a high-value attack surface.

Test:

Token uniqueness
Token expiration
Token invalidation
Token reuse
User-ID manipulation
Email parameter manipulation
Host-header-related issues
Password reset session handling
Rate limiting
Reset-token leakage
Referer leakage
Account enumeration
Whether old reset links remain valid

A secure password-reset flow should bind the reset operation to the correct account and invalidate tokens appropriately.

10. Session Management

Review:

Session token randomness
Token predictability
Session expiration
Logout behavior
Session invalidation
Session fixation
Concurrent sessions
Cookie scope
Secure flag
HttpOnly flag
SameSite configuration
Cross-device session behavior

Also verify whether previously issued sessions remain valid after:

Password changes
Password resets
Account recovery
Privilege changes
MFA changes
Logout

11. Authorization and IDOR

Authorization testing should be performed with multiple test accounts whenever possible.

Look for identifiers such as:

/user/123
/account/456
/order/789
/ticket/321

/user/123
/account/456
/order/789
/ticket/321

Change identifiers and verify whether the server correctly enforces ownership.

Test:

Horizontal privilege escalation
Vertical privilege escalation
Object-level authorization
Function-level authorization
API authorization
Administrative endpoints
File access
Export functionality
Invoice/PDF access
Ticket systems
Shipment information

Never assume that hiding an object ID provides security.

12. Input Validation

Identify every location where user-controlled data enters the application.

Test:

Query parameters
POST parameters
JSON bodies
Headers
Cookies
Path parameters
File names
HTTP methods
API parameters

Potential vulnerability classes include:

XSS
SQL injection
NoSQL injection
LDAP injection
XPath injection
Command injection
Path traversal
Local file inclusion
Remote file inclusion
SSRF
XXE
SSTI
Open redirect
HTTP request smuggling
HTTP parameter pollution

The goal is not simply to inject payloads everywhere; understand how each input flows through the application.

13. Cross-Site Scripting

Check for:

Reflected XSS

Identify user-controlled values that are reflected into responses.

Stored XSS

Test fields that persist data, such as:

Profiles
Comments
Addresses
Support tickets
Product descriptions
User-generated content

DOM XSS

Inspect JavaScript for dangerous data flows and DOM sinks.

Always determine the actual execution context before concluding that a reflection is exploitable.

14. File Upload Testing

File upload functionality deserves careful testing.

Review:

Extension validation
MIME validation
File signature validation
Filename handling
File size restrictions
Storage location
Public accessibility
Filename traversal
Metadata handling
Image processing
Archive processing

Also determine whether uploaded files are:

Executed
Served directly
Processed by another service
Stored in cloud storage

15. SSRF Testing

Look for server-side URL fetching functionality.

Common examples:

URL preview
Webhooks
Import functionality
Image fetching
PDF generation
Remote integrations
Link scanners

Understand where the server makes the request and what network resources it can access.

16. HTTP Request Smuggling

Where applicable, examine differences between:

Front-end proxy
CDN
Load balancer
Reverse proxy
Application server

Pay attention to inconsistent handling of HTTP request boundaries.

This class of vulnerability generally requires careful testing because malformed requests can affect other users.

17. CORS

Review CORS behavior for sensitive endpoints.

Check:

Reflected origins
Wildcard origins
Credentialed requests
Origin validation
Null origin behavior
Sensitive data exposure

A permissive CORS policy is not automatically a vulnerability; impact depends on what authenticated data or actions become accessible.

18. Business Logic Testing

Technical vulnerabilities are not the only important bugs.

Understand how the application actually works.

Test:

Price manipulation
Quantity manipulation
Discount abuse
Coupon reuse
Workflow bypass
Step skipping
Transaction replay
Unauthorized state changes
Client-side validation reliance
Race conditions
Duplicate transactions
Account workflow abuse

For example, if an application requires:

Create → Verify → Approve → Pay

Create → Verify → Approve → Pay

test whether individual stages can be skipped or performed out of order.

19. Payment Functionality

For applications involving payments, examine:

Price calculation
Product IDs
Quantity
Currency
Discount values
Payment status
Transaction IDs
Refund logic
Invoice generation
Order ownership

Never use real financial information when testing a bug-bounty target unless explicitly authorized.

20. Error Handling

Error messages can reveal valuable information.

Try unexpected but controlled inputs and observe:

Stack traces
Framework information
File paths
Database errors
Debug messages
Internal hostnames
Version information
Configuration details

Compare application behavior across different HTTP methods and malformed requests.

21. Security Headers

Review important response headers such as:

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Cache-Control

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Cache-Control

Remember that missing a security header is not necessarily a reportable vulnerability. Evaluate its actual security impact.

22. Infrastructure Testing

Where infrastructure testing is within scope, examine:

Open TCP ports
UDP services
DNS configuration
TLS configuration
Cloud assets
Virtual hosts
Alternative application hosts
Internal IP disclosure
External IP exposure
Storage buckets
Web server configuration

Useful tools may include:

nmap
testssl.sh
Shodan
DNS enumeration tools

23. Email Security

Review:

SPF
DKIM
DMARC
Mail-server configuration
Password-reset email behavior
Account-verification email behavior

Email-related weaknesses can sometimes become account takeover vulnerabilities when combined with application flaws.

24. CAPTCHA and Rate Limiting

For functionality protected by CAPTCHA or rate limits, verify that the protection is actually enforced server-side.

Check:

Request replay
Session binding
Expiration
Endpoint consistency
Alternate API endpoints
Different HTTP methods
Whether rate limits apply per account, IP, or other identifier

Avoid aggressive testing against production systems.

25. Automated Scanning

Automation is useful, but it should support — not replace — manual testing.

A possible workflow:

Recon
  ↓
Asset Discovery
  ↓
Live Host Identification
  ↓
URL Collection
  ↓
Parameter Discovery
  ↓
Technology Fingerprinting
  ↓
Automated Scanning
  ↓
Manual Validation
  ↓
Business Logic Testing
  ↓
Impact Verification
  ↓
Reporting

Recon
  ↓
Asset Discovery
  ↓
Live Host Identification
  ↓
URL Collection
  ↓
Parameter Discovery
  ↓
Technology Fingerprinting
  ↓
Automated Scanning
  ↓
Manual Validation
  ↓
Business Logic Testing
  ↓
Impact Verification
  ↓
Reporting

Tools such as nuclei can help identify known patterns, while tools such as Burp Suite remain useful for manually understanding application behavior.

26. Maintain an Asset Inventory

Keep organized files for your assessment.

For example:

all_subdomains.txt
live_hosts.txt
historical_urls.txt
directories.txt
parameters.txt
javascript_files.txt
api_endpoints.txt
github_findings.txt
nmap_results.txt
interesting_hosts.txt
potential_vulnerabilities.txt

all_subdomains.txt
live_hosts.txt
historical_urls.txt
directories.txt
parameters.txt
javascript_files.txt
api_endpoints.txt
github_findings.txt
nmap_results.txt
interesting_hosts.txt
potential_vulnerabilities.txt

Organization becomes especially important when the target contains hundreds or thousands of assets.

27. Build Your Own Test Cases

Do not rely entirely on generic checklists.

For every application, create a custom attack-surface map.

Ask:

What does this application do?
What data does it protect?
What roles exist?
Which actions require authorization?
Which workflows involve money?
Which objects belong to individual users?
Which APIs communicate with external systems?
Where does the application trust client-side data?
What happens when a workflow is interrupted?
What happens when requests are replayed?

This is where experienced testers often find bugs that automated scanners miss.

Final Workflow

A practical web pentesting methodology can be summarized as:

1. Understand scope
2. Enumerate assets
3. Identify live systems
4. Fingerprint technologies
5. Discover URLs and parameters
6. Analyze JavaScript
7. Map authentication
8. Map authorization
9. Test sessions
10. Test input handling
11. Test file uploads
12. Test APIs
13. Test business logic
14. Review infrastructure
15. Automate repetitive checks
16. Manually validate findings
17. Confirm impact safely
18. Document everything
19. Report clearly

1. Understand scope
2. Enumerate assets
3. Identify live systems
4. Fingerprint technologies
5. Discover URLs and parameters
6. Analyze JavaScript
7. Map authentication
8. Map authorization
9. Test sessions
10. Test input handling
11. Test file uploads
12. Test APIs
13. Test business logic
14. Review infrastructure
15. Automate repetitive checks
16. Manually validate findings
17. Confirm impact safely
18. Document everything
19. Report clearly

Final Thoughts

A checklist is a starting point — not a substitute for understanding the application.

The most valuable mindset is:

Don't just look for vulnerabilities. Understand why the application trusts the user, where that trust crosses a security boundary, and whether that trust can be abused.

Use automation for scale, Burp Suite for interaction, reconnaissance tools for visibility, and manual reasoning for the vulnerabilities that require understanding business logic.

Happy hunting. 🔎

Original reference: Pentest Book — Pentesting Web Checklist.

Only perform security testing against systems you own or have explicit authorization to test.

Contents

1. Reconnaissance

1.1 Define the Scope

1.2 Large-Scope Recon

1.3 Domain and Subdomain Enumeration

1.4 Identify Live Hosts

2. Web Application Discovery

Files and Endpoints Worth Checking

Directory and File Discovery

3. Technology Fingerprinting

4. URL and Parameter Discovery

5. JavaScript Analysis

6. Authentication Testing

Registration

7. Login Testing

8. Multi-Factor Authentication

9. Password Reset

10. Session Management

11. Authorization and IDOR

12. Input Validation

13. Cross-Site Scripting

Reflected XSS

Stored XSS

DOM XSS

14. File Upload Testing

15. SSRF Testing

16. HTTP Request Smuggling

17. CORS

18. Business Logic Testing

19. Payment Functionality

20. Error Handling

21. Security Headers

22. Infrastructure Testing

23. Email Security

24. CAPTCHA and Rate Limiting

25. Automated Scanning

26. Maintain an Asset Inventory

27. Build Your Own Test Cases

Final Workflow

Final Thoughts