Web Application Penetration Testing Checklist: What to Test

• Offensium Vault
• October 21, 2026
• No Comments

Web applications are where most businesses meet their customers, take payments and store personal data, which also makes them a favourite target for attackers. Web application penetration testing is the most reliable way to find out how an attacker could break in, because skilled testers attack your application the way a real adversary would, with permission and within an agreed scope.

This web application penetration testing checklist explains what a thorough test should cover, how the checks map to the latest OWASP Top 10, and what you should expect in the final report. Use it to scope your next test, or to check whether a provider’s methodology goes deep enough.

What Is Web Application Penetration Testing?

Web application penetration testing is a security assessment in which testers look for vulnerabilities in a web application and try to exploit them safely to prove their real-world impact. Unlike a quick automated scan, a proper test combines tools with manual techniques, examines how features behave for different users and roles, and validates every finding before it is reported.

It is usually delivered as part of VAPT (vulnerability assessment and penetration testing). If you are unsure how the two halves differ, our guide to vulnerability assessment vs penetration testing explains it in detail.

Before Testing: Scoping and Preparation

Good results start before any testing begins. Agree the following with your provider:

• Scope: the exact URLs, subdomains, APIs and environments to be tested, and anything that is out of scope.
• Environment: production or a staging copy that mirrors production as closely as possible.
• Test accounts: at least two accounts for every user role, so testers can check whether one user can access another user’s data.
• Testing approach: black box (no prior knowledge), grey box (accounts and some documentation) or white box (including source code).
• Rules of engagement: testing windows, contacts for emergencies, and techniques that are not allowed, such as denial-of-service.
• Confidentiality: an NDA and a clear agreement on how data and findings will be handled.

The Web Application Penetration Testing Checklist

A comprehensive test should cover each of the areas below. The OWASP Web Security Testing Guide is a widely used reference for the detailed test cases behind them.

1. Reconnaissance and Application Mapping

• Identify all reachable pages, endpoints, parameters and hidden functionality.
• Fingerprint frameworks, servers and third-party components and their versions.
• Look for exposed files, backups, debug pages, admin panels and source maps.

2. Authentication

• Test password policy, account lockout and protection against brute-force and credential stuffing.
• Check password reset, email verification and “remember me” flows for logic flaws.
• Verify multi-factor authentication cannot be bypassed or skipped.

3. Session Management

• Confirm session tokens are random, sufficiently long and protected with Secure, HttpOnly and SameSite cookie attributes.
• Check that sessions expire after logout, inactivity and password change.
• Test for session fixation and cross-site request forgery (CSRF).

4. Access Control and Authorisation

• Attempt to access other users’ records by changing IDs in requests (IDOR).
• Test whether a normal user can reach admin functions or APIs (privilege escalation).
• Check that restrictions are enforced on the server, not only hidden in the user interface.

5. Input Validation and Injection

• Test for SQL, NoSQL, command and template injection.
• Check for cross-site scripting (reflected, stored and DOM-based).
• Look for server-side request forgery (SSRF), XML external entities and path traversal.

6. Business Logic

• Try to skip steps in multi-step workflows such as checkout, onboarding or approvals.
• Manipulate prices, quantities, coupons, limits and race conditions.
• Abuse features in ways the developers did not intend.

7. File Uploads

• Upload files with dangerous types, double extensions or malicious content.
• Check that uploaded files cannot be executed and are stored and served safely.

8. Configuration and Security Headers

• Review TLS configuration, HTTP security headers and CORS policy.
• Check for default credentials, verbose banners and unnecessary HTTP methods.
• Review cloud storage and other infrastructure the application depends on.

9. Data Protection and Cryptography

• Confirm sensitive data is encrypted in transit and, where appropriate, at rest.
• Check that secrets, keys and personal data are not exposed in responses, logs or client-side code.

10. Error Handling, Logging and Third-Party Components

• Trigger errors to see whether stack traces or internal details leak.
• Check whether important security events are logged.
• Identify outdated libraries and components with known vulnerabilities.

Most modern web applications rely heavily on APIs, so these should be tested too. Our API security assessment guide covers the extra checks involved.

Mapping the Checklist to the OWASP Top 10:2025

The OWASP Top 10:2025 lists the most critical web application security risks. Here is how the checklist above covers each one:

Automated Scanning vs Manual Penetration Testing

Automated scanners are fast and good at spotting known vulnerabilities, missing headers and outdated components. However, they struggle with the issues that often cause the most damage: broken access control between users, flawed business logic and chained attacks that combine several minor weaknesses. Manual testing by experienced testers is what finds these.

The best approach uses both: tools for coverage and speed, and manual testing for depth and accuracy. Every finding should be manually verified so your developers do not waste time on false positives.

What a Good Penetration Test Report Should Include

• An executive summary that explains risk in business terms for leadership.
• A clear scope and methodology section.
• Each finding with severity, affected URLs, evidence and steps to reproduce.
• Practical remediation guidance your developers can act on.
• A retest to confirm that fixes have closed each issue.

If your application also stores sensitive logic in code you own, combining the test with a secure source code review can uncover issues that are hard to find from the outside.

Frequently Asked Questions

How long does a web application penetration test take?

It depends on the size and complexity of the application, the number of user roles and whether APIs are included. A small application may take a few days, while a large platform with many roles and integrations can take a few weeks. A scoping call is the best way to get an accurate timeline.

Is automated scanning enough to secure a web application?

No. Scanners are useful for finding known issues and misconfigurations quickly, but they cannot understand business logic, chain multiple weaknesses together or reliably test access control between users and roles. A thorough test combines automated tools with manual testing by experienced testers.

How often should we test our web application?

Most organisations test at least once a year and after any significant change, such as a major release, new payment or login flow, new integration or infrastructure migration. Applications that handle payments or sensitive personal data often benefit from more frequent testing.

Conclusion

A strong web application penetration testing engagement covers far more than a scanner can: authentication, sessions, access control, injection, business logic, configuration and third-party components, all mapped to the OWASP Top 10 and backed by clear evidence. Use this checklist to scope your next test and to hold any provider to a high standard.

Planning a test for your web application? Contact the Offensium Vault team for a scoping call, or explore our full range of cybersecurity services.