Web Application Penetration Testing Checklist: A Practical Guide

What Is a Web Application Penetration Test

A web application penetration test is a controlled, authorised attempt to exploit vulnerabilities in a web application. The tester adopts the mindset and techniques of an attacker while operating within agreed rules of engagement that protect both the tester and the target organisation. The objective is not simply to find vulnerabilities but to demonstrate their real-world impact: can an attacker steal user data, escalate privileges, access administrative functions, or compromise backend systems through the web application?

Penetration testing differs from vulnerability scanning in several important ways. Scanners run automated checks against known vulnerability signatures, while penetration testers use creativity, domain knowledge, and manual techniques to discover issues that scanners miss. Scanners report individual findings in isolation, while penetration testers chain multiple lower-severity findings together to demonstrate high-impact attack paths. Scanners produce technical output, while penetration testers produce narrative reports that explain risk in business context.

Web application penetration tests typically follow established methodologies such as the OWASP Testing Guide, PTES (Penetration Testing Execution Standard), or OSSTMM (Open Source Security Testing Methodology Manual). These methodologies provide structured checklists that ensure comprehensive coverage while allowing the tester flexibility to investigate application-specific issues. The checklist below synthesises the key testing areas from these methodologies into a practical workflow for web application testing engagements. If you are still choosing your testing tools, our penetration testing tools comparison covers Burp Suite, OWASP ZAP, Nessus, Metasploit, and more with honest pros, cons, and pricing.

Pre-Engagement: Scoping and Rules of Engagement

The pre-engagement phase establishes the foundation for a successful penetration test. Inadequate scoping is one of the most common reasons penetration tests fail to deliver value. The scope must clearly define which applications, URLs, and API endpoints are included; which environments (production, staging, development) will be tested; whether testing is black-box (no credentials), grey-box (standard user credentials), or white-box (credentials plus source code access); and any exclusions such as specific functionality, IP ranges, or testing times.

Rules of engagement document the boundaries of the test. They specify whether denial of service testing is permitted, whether social engineering is in scope, what to do if critical vulnerabilities are found during testing, escalation contacts for emergencies, and the testing window including permitted hours and blackout periods. Both parties must sign the rules of engagement before testing begins. This document protects the tester legally and ensures the client knows exactly what to expect.

Gather the information needed to begin testing: application URLs, test account credentials with different roles if grey-box or white-box testing, API documentation, architecture diagrams, and any previous assessment reports. Set up your testing environment with the necessary tools: an intercepting proxy, browser extensions, automated scanners, and your reporting platform. Document the scope, rules of engagement, and testing timeline in your engagement management system so there is a clear record of what was agreed before testing starts.

Reconnaissance and Information Gathering

Reconnaissance is the process of gathering information about the target application to inform your testing approach. Start with passive reconnaissance: examining the application without sending any requests beyond normal browsing. Review the application's technology stack using browser developer tools, checking response headers for server software, frameworks, and CDN information. Examine JavaScript files for API endpoints, internal paths, developer comments, and hardcoded values. Check robots.txt and sitemap.xml for paths the application explicitly excludes from search engine indexing, which often reveals administrative or sensitive functionality.

Active reconnaissance involves interacting with the application to map its functionality. Browse every accessible page, submit every form, trigger every user flow, and document the application's complete functionality. Map the URL structure and identify patterns: does the application use predictable resource identifiers (e.g., /users/123, /invoices/456) that could be vulnerable to insecure direct object references? Identify all input points: form fields, URL parameters, HTTP headers, cookies, file upload fields, and API endpoints. Each input point is a potential attack vector that must be tested.

Document the application's authentication mechanisms, session management approach, and access control model during reconnaissance. Understanding how the application handles authentication (username/password, OAuth, SSO, MFA) and how it manages sessions (cookies, JWT tokens, server-side sessions) informs the testing approach for subsequent phases. Identify the different user roles and their expected permissions, as testing access controls requires understanding what each role should and should not be able to access. This reconnaissance data forms the basis of your testing plan and ensures you do not miss functionality during the testing phase.

Authentication and Session Management Testing

Authentication is the application's first line of defence, and weaknesses here can undermine every other security control. Test the login mechanism for brute-force resistance: does the application lock accounts or implement rate limiting after failed attempts? Test with common username/password combinations and check whether the application reveals whether a username exists through different error messages for valid versus invalid usernames. Test password reset functionality for account takeover vulnerabilities: can the reset token be predicted, does the reset link expire appropriately, and is the reset process vulnerable to host header injection?

Session management testing verifies that authenticated sessions are handled securely. Examine session tokens for entropy: are they sufficiently random and unpredictable? Check cookie attributes: are session cookies marked HttpOnly, Secure, and SameSite? Test for session fixation by checking whether the application issues a new session token after successful authentication. Test session termination by logging out and attempting to reuse the session token. For applications using JWT tokens, test for common JWT vulnerabilities: algorithm confusion (switching from RS256 to HS256), none algorithm acceptance, weak signing keys, and token expiration enforcement.

If the application implements multi-factor authentication (MFA), test whether it can be bypassed. Common MFA bypass techniques include testing whether the MFA step can be skipped by directly navigating to post-MFA URLs, whether MFA codes are rate-limited, whether backup codes are predictable, and whether the MFA enrollment process is secure. Test authenticated scanning capabilities by verifying that your testing tools can maintain valid sessions throughout the scan while respecting the application's session management controls.

Input Validation and Injection Testing

Injection testing is the process of sending crafted input to the application to determine whether it is properly validated and sanitised before being processed. Test every input point identified during reconnaissance for multiple injection types. SQL injection testing involves sending payloads that attempt to modify database queries: single quotes, UNION SELECT statements, boolean-based payloads, and time-based blind injection payloads. Test both standard form fields and less obvious inputs like HTTP headers, cookie values, and JSON API parameters.

Cross-site scripting (XSS) testing checks whether the application reflects or stores user input without proper encoding. Test for reflected XSS by injecting script tags, event handlers, and encoding bypasses in URL parameters and form fields. Test for stored XSS in any functionality that persists user input: comments, profile fields, file names, and metadata. Test for DOM-based XSS by examining client-side JavaScript for patterns where URL fragments, query parameters, or other controllable inputs are written directly to the DOM without sanitisation.

Beyond SQL injection and XSS, test for command injection in functionality that interacts with the operating system (file operations, system commands, DNS lookups). Test for Server-Side Request Forgery (SSRF) in functionality that fetches external resources (URL preview, webhook delivery, file import). Test for XML External Entity (XXE) injection in applications that parse XML input. Test for template injection in applications using server-side template engines. Test file upload functionality for path traversal, unrestricted file types, and content-type mismatches. Each injection type requires specific payloads and detection techniques, and automated scanners should be supplemented with manual testing for each category.

Access Control and Authorisation Testing

Access control testing verifies that the application enforces proper authorisation at every level: feature access, data access, and administrative function access. This is one of the most important testing areas because broken access control is consistently the number one web application security risk in the OWASP Top 10, and it is the category most frequently missed by automated scanners.

Test horizontal privilege escalation by authenticating as one user and attempting to access another user's data. If the application uses predictable identifiers (e.g., /api/users/123/profile), change the identifier to another user's value and check whether the application returns the other user's data. This test must be performed across all resource types: user profiles, documents, transactions, settings, and any other user-specific data. Test vertical privilege escalation by authenticating as a standard user and attempting to access administrative functionality. Can a regular user access admin endpoints by guessing the URL? Do API endpoints enforce role-based access controls, or do they only check authentication?

Test for insecure direct object references (IDOR) across all API endpoints. Document every endpoint that accepts a resource identifier and verify that the application checks whether the authenticated user is authorised to access that specific resource. Test function-level access controls by verifying that sensitive operations (delete, modify, export, invite) check the user's role before executing. Test multi-tenant isolation by verifying that users in one tenant cannot access data from another tenant. Access control testing is inherently manual because automated tools cannot understand the application's intended authorisation model. Use findings management to document each access control finding with the specific endpoint, the test performed, and the expected versus actual behaviour.

Business Logic Testing

Business logic vulnerabilities are flaws in the application's workflow and decision-making processes that allow attackers to misuse legitimate functionality for unintended purposes. These vulnerabilities cannot be detected by automated scanners because they require understanding the application's intended behaviour and identifying deviations from that intent. Business logic testing is where the penetration tester's expertise and creativity deliver the most unique value.

Test workflow bypass by attempting to skip steps in multi-step processes. Can a user complete a purchase without going through the payment step? Can a user submit a form without completing required verification? Test for race conditions by sending concurrent requests to functionality that should be atomic: applying discount codes, transferring funds, claiming limited resources, or voting. Test numeric handling by submitting negative values, zero values, extremely large values, and decimal values where integers are expected. Can a user order negative quantities to generate a refund? Can a user transfer a negative amount to receive funds?

Test for data leakage through error conditions and boundary cases. What happens when the application encounters unexpected input, concurrent operations, or resource exhaustion? Do error messages reveal internal implementation details, stack traces, database table names, or file paths? Test rate limiting and abuse prevention: can a user send unlimited emails through the contact form, create unlimited trial accounts, or abuse referral bonuses? Test data validation consistency by checking whether the client-side validation rules match the server-side validation. If the client enforces a maximum length of 100 characters but the server accepts 10,000, the application may be vulnerable to denial of service or buffer-related issues.

Reporting and Remediation Tracking

The penetration test report is the primary deliverable and the basis for the client's remediation effort. A good report serves multiple audiences: executive leadership needs a summary of the overall risk posture and the most critical findings, development teams need specific technical details and remediation guidance for each vulnerability, and compliance teams need evidence that the testing was conducted according to methodology and covers the required scope (particularly for SOC 2 and ISO 27001 audits, where penetration test reports serve as direct evidence). Writing effective reports is a skill that distinguishes professional penetration testing from amateur vulnerability scanning. For detailed guidance, see how to write a pentest report.

Each finding should include a clear title, severity rating using CVSS, a description of the vulnerability, steps to reproduce, evidence (screenshots, HTTP request/response pairs, code snippets), the potential business impact, and specific remediation guidance. The remediation guidance should be actionable: rather than stating "fix the SQL injection," specify "use parameterised queries with prepared statements in the /api/search endpoint, replacing the string concatenation on line 42 of search-handler.js." The more specific the guidance, the faster the development team can implement the fix.

After the report is delivered, the remediation phase begins. Track which findings have been addressed, which are in progress, and which are accepted risks. Schedule a retest to verify that the remediations are effective and have not introduced new vulnerabilities. Retesting should cover not only the specific findings but also regression testing around the modified functionality. Deliver the final report through a secure channel, ideally a findings management platform where the client can track remediation status rather than a static PDF that quickly becomes outdated.

Quick Reference Checklist