Web Application Penetration Testing Checklist (OWASP-Based)

Not all "penetration tests" cover the same ground. This OWASP-aligned checklist shows what a thorough web application assessment should include — useful both for scoping a test and for judging whether a report you've received actually did the work.

Before testing: reconnaissance and mapping

A good test starts by understanding the application, not firing off scanners:

• Map every page, endpoint, and parameter (authenticated and unauthenticated).
• Identify technologies, frameworks, and versions.
• Enumerate user roles and trust boundaries.
• Review how sessions, tokens, and cookies are issued and handled.

Authentication

• Weak or missing password policy; credential-stuffing resistance.
• Username enumeration via login, registration, or reset flows.
• Brute-force protection and account lockout.
• Multi-factor authentication implementation flaws.
• Password reset logic (token predictability, reuse, host-header poisoning).
• "Remember me" and session persistence handling.

Session management

• Session token entropy and predictability.
• Secure, HttpOnly, and SameSite cookie flags.
• Session fixation and proper invalidation on logout.
• Token lifetime and idle timeout.

Access control (authorization)

This is where the most damaging real-world bugs live:

• Broken Object Level Authorization (BOLA/IDOR) — can user A access user B's records by changing an ID?
• Vertical privilege escalation — can a standard user reach admin functions?
• Horizontal privilege escalation — can a user act on peers' data?
• Forced browsing to unlinked but unprotected endpoints.
• Access control enforced on the server, not just hidden in the UI.

Input validation and injection

• SQL injection and other database injections.
• Cross-Site Scripting (XSS) — reflected, stored, and DOM-based.
• Command, LDAP, XML/XXE, and template injection.
• Server-Side Request Forgery (SSRF).
• File upload handling (type, size, content, storage location).

Business logic

Scanners cannot find these — they require a human who understands the application:

• Bypassing multi-step workflows (e.g., skipping payment).
• Manipulating prices, quantities, or discounts.
• Race conditions in critical operations.
• Abusing "forgot password," referral, or coupon logic.

Configuration and infrastructure

• Security headers (Content-Security-Policy, HSTS, X-Content-Type-Options).
• TLS configuration and certificate validity.
• Verbose errors and information disclosure.
• Default credentials and exposed admin panels.
• Directory listing and exposed backup/config files.

API and client-side

If the app is backed by an API, that surface needs its own attention — see our note on API security testing. On the client side, check for secrets in JavaScript, insecure use of local storage, and unsafe third-party scripts.

The OWASP Top 10 as a backbone

A credible test maps findings to a recognised framework. The OWASP Top 10 — Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Identification & Authentication Failures, Software & Data Integrity Failures, Logging & Monitoring Failures, and SSRF — is the industry baseline. Ask that your report references it so findings are contextualised, not just listed.

After the test: what a good report gives you

• An executive summary for leadership.
• Findings rated by severity (CVSS) with clear business impact.
• Reproduction steps and evidence for each issue.
• Actionable remediation guidance, not just "fix this."
• A retest to confirm fixes and issue a clean report.

How TestUnity tests

Our web application penetration testing follows this methodology — manual, OWASP-aligned, and focused on the access-control and business-logic flaws that automated tools miss — with a retest included. Scope a web app pentest with our team.

FAQ

Can automated scanning tools cover everything on this checklist?

No. Automated scanners are good at finding known vulnerability patterns like outdated components or missing security headers, but they cannot detect access-control flaws such as BOLA/IDOR, or business-logic issues like bypassing a multi-step checkout — both require a human tester who understands what the application is supposed to do.

What's the difference between vertical and horizontal privilege escalation?

Vertical privilege escalation is a standard user reaching admin-level functionality they shouldn't have access to. Horizontal privilege escalation is a user accessing or modifying another user's data at the same permission level — for example, viewing a peer's order history by changing an ID in the URL.

Why does the report need a retest, not just a list of findings?

A findings list tells you what's broken; a retest confirms the fixes actually worked and didn't introduce new issues. Without it, you're relying on the development team's word that a vulnerability is closed, which is a weak basis for a clean audit trail or compliance evidence.

How does this checklist relate to the OWASP Top 10?

The OWASP Top 10 is the backbone categories — Broken Access Control, Injection, Security Misconfiguration, and so on — while this checklist is the practical work needed to test for each category in a real application: reconnaissance, authentication, session management, access control, input validation, business logic, and infrastructure configuration.