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.