Web Application Penetration Testing Checklist (2026, OWASP-Based)

Last updated: 16 October 2026. Written by Josh Hutcheson, OnlineCourseing editor. Checked against the OWASP Web Security Testing Guide v4.2 and the OWASP Top 10:2025. See our review methodology.

This checklist is written for developers who want to test their own applications, students learning web security, and junior testers who need a structured list to work from. It tells you what to check. It does not give attack payloads; the WSTG explains each test in full, and the practice labs listed below teach the technique safely.

Before you start: scope and written permission

Every legitimate test starts with authorization. Agree in writing what is in scope (domains, environments, user roles, APIs), what is out of scope, the testing window, and who to call if something breaks. Prefer a staging environment with test data. If you are not the owner, the person signing must have the authority to grant permission for every system in scope, including third-party hosting and cloud services, which often have their own testing rules.

Our guide to whether ethical hacking is legal covers authorization and the US Computer Fraud and Abuse Act in more detail. For how a full engagement runs, from planning to reporting, see our penetration testing methodology guide.

Pre-test checklist

• Written authorization signed by someone with the authority to give it
• Scope document: hosts, URLs, APIs, user roles and environments in and out of scope
• Test accounts for every role you will test (at least two users per role, to test access between accounts)
• Agreed testing window, rate limits and a contact for incidents
• Backups or a disposable environment, so a failed test cannot damage real data
• A place to log every request and finding with timestamps

How to use this checklist

Work through the 12 areas in order, because early areas feed later ones: mapping the application in area 1 tells you which login, upload and API features to test later. Mark each item pass, fail or not applicable, and record the evidence. The section numbers match the WSTG (4.1 to 4.12), so you can open the guide for the full test description of any item.

Practitioners on r/AskNetsec make two points worth repeating. First, map the application and test it feature by feature (login, search, checkout, file upload), not one vulnerability class at a time across the whole site. Second, the flaws that slip past automated scanners are usually authorization and business-logic problems, so give areas 5 and 10 real time.

1. Information gathering

Find out what is running and what is exposed before testing anything. Most later checks depend on this map.

• Search engines and public sources do not expose sensitive pages, documents or credentials
• The web server, framework and application are fingerprinted, and their versions noted
• Metafiles such as robots.txt and sitemaps do not reveal hidden or sensitive paths
• Every application and admin interface on the server is identified
• Page source and comments do not leak keys, internal hostnames or debug notes
• All entry points are listed: forms, parameters, headers, cookies and API endpoints
• Execution paths and the application architecture (proxies, load balancers, third-party services) are mapped

Why it matters: Missed entry points are untested entry points. A forgotten admin panel or an old API version is often the weakest part of an application.

WSTG section 4.1. Related OWASP Top 10:2025 risk: A02 Security Misconfiguration.

2. Configuration and deployment management

Check that the platform the application runs on is configured safely.

• Network and application platform settings follow the vendor’s hardening guidance
• Old backups, unreferenced files and unused file extensions do not expose source code or data
• Admin interfaces are not reachable from the public internet, or are strongly protected
• Only the HTTP methods the application needs are enabled
• HTTP Strict Transport Security (HSTS) is set
• File permissions on the server are as narrow as possible
• DNS records do not point to unclaimed cloud resources (subdomain takeover)
• Cloud storage buckets are not publicly readable or writable

Why it matters: Misconfiguration rose to second place in the 2025 Top 10. It needs no clever attack, only a setting left open.

WSTG section 4.2. Related OWASP Top 10:2025 risk: A02 Security Misconfiguration.

3. Identity management

Check how accounts are created, provisioned and named.

• Roles are defined, documented and match what the application actually allows
• Self-registration verifies identity to the level the application needs
• Account provisioning cannot be abused to create privileged accounts
• Login, registration and reset pages do not reveal which usernames exist
• Usernames are not guessable from a predictable pattern

Why it matters: If an attacker can list valid accounts, every password attack becomes far more effective.

WSTG section 4.3. Related OWASP Top 10:2025 risk: A07 Authentication Failures.

4. Authentication

Check that the application proves who a user is, every time and through every channel.

• Credentials are only ever sent over an encrypted connection
• No default or vendor credentials remain active
• Lockout or rate limiting slows repeated login attempts without letting attackers lock out real users
• Authentication cannot be skipped by going directly to a protected page or changing a parameter
• “Remember me” functions and browser caching do not store credentials or sensitive pages
• The password policy meets current guidance (length over complexity rules) and security questions are not weak
• Password change and reset require the old password or a secure, expiring token
• Alternative channels (mobile app, API, single sign-on) are as strong as the main login

Why it matters: Authentication is the front door. A weak reset flow or a mobile API without the same controls is a common way round a strong login page.

WSTG section 4.4. Related OWASP Top 10:2025 risk: A07 Authentication Failures.

5. Authorization

Check that each user can reach only the data and functions their role allows.

• Directory traversal and file inclusion cannot read files outside the intended folders
• Pages and API calls check permissions on the server, not only by hiding buttons
• A normal user cannot perform admin actions (vertical privilege escalation)
• One user cannot read or change another user’s records by changing an ID (insecure direct object references)
• Server-side requests to URLs a user supplies are restricted, so they cannot reach internal systems (SSRF)

Why it matters: Broken access control has been the number one risk in the OWASP Top 10 since 2021, and in 2025 it also absorbed server-side request forgery. Test it with two accounts per role.

WSTG section 4.5. Related OWASP Top 10:2025 risk: A01 Broken Access Control.

6. Session management

Check that once a user is logged in, their session cannot be stolen, reused or forged.

• Session tokens are long, random and change at login
• Cookies carry the Secure, HttpOnly and SameSite attributes
• Session fixation is not possible (a token set before login is not kept after it)
• Session tokens do not appear in URLs, logs or error messages
• State-changing requests are protected against cross-site request forgery (CSRF)
• Logout ends the session on the server, not only in the browser
• Idle and absolute session timeouts are enforced
• The same session variable is not reused for different purposes (session puzzling)

Why it matters: A stolen session is as good as a stolen password, and it bypasses multi-factor authentication.

WSTG section 4.6. Related OWASP Top 10:2025 risk: A07 Authentication Failures.

7. Input validation

This is the largest area in the WSTG. Check that every input the application accepts is validated and handled safely before it reaches a browser, database, operating system or another service.

• Output is encoded so user input cannot run as script in other users’ browsers (reflected and stored cross-site scripting)
• Database queries use parameterized statements, so input cannot change the query (SQL and NoSQL injection)
• Input never reaches operating-system commands, LDAP, XML, XPath or mail headers unvalidated
• Templates do not evaluate user input (server-side template injection)
• Duplicate or unexpected parameters and HTTP verbs are handled consistently
• The Host header and other incoming headers are not trusted for links or routing
• Front-end and back-end servers agree on where each request ends (HTTP request smuggling)
• Stored input that is processed later (in reports, emails or admin panels) is also validated

Why it matters: Injection is fifth in the 2025 Top 10. One unvalidated field is enough, and injection flaws often expose the whole database behind the application.

WSTG section 4.7. Related OWASP Top 10:2025 risk: A05 Injection.

8. Error handling

Check what the application reveals when something goes wrong.

• Error pages are generic and do not show stack traces, file paths, queries or version numbers
• Unexpected input produces a controlled error, not a crash or a half-finished transaction
• When a check fails, the application fails closed (denies the action) rather than open

Why it matters: Mishandling of exceptional conditions is a new category in the 2025 Top 10. Verbose errors also hand attackers the information gathered in area 1.

WSTG section 4.8. Related OWASP Top 10:2025 risk: A10 Mishandling of Exceptional Conditions.

9. Weak cryptography

Check that data is protected in transit and at rest with current algorithms.

• TLS is enforced with current protocol versions and strong cipher suites
• Padding oracle weaknesses are not present in encrypted values the application handles
• No sensitive data is sent over unencrypted channels, including internal calls and email links
• Passwords are stored with a slow, salted hashing algorithm, and other sensitive data with current encryption

Why it matters: Cryptographic failures expose data even when every other control works.

WSTG section 4.9. Related OWASP Top 10:2025 risk: A04 Cryptographic Failures.

10. Business logic

Check that the application’s rules cannot be bent. Scanners rarely find these flaws because they depend on what the application is supposed to do.

• Data is validated against business rules on the server (prices, quantities, dates, limits)
• Requests cannot be forged to skip steps or change hidden values
• Integrity checks cannot be bypassed by editing data the client sends back
• Timing does not leak information or allow race conditions (for example, redeeming one voucher twice)
• Limits on how often a function can be used are enforced (coupons, votes, password resets)
• Multi-step workflows cannot be completed out of order
• The application detects and responds to misuse, such as many failed actions in a row
• File uploads accept only expected file types and are scanned and stored safely

Why it matters: Logic flaws are where experienced testers find the issues automated tools miss. Insecure design is sixth in the 2025 Top 10.

WSTG section 4.10. Related OWASP Top 10:2025 risk: A06 Insecure Design.

11. Client-side

Check the code that runs in the user’s browser.

• DOM-based cross-site scripting and HTML injection are not possible through URL fragments or client-side code
• Client-side redirects only go to approved destinations
• Cross-origin resource sharing (CORS) allows only trusted origins
• Pages that should not be framed send the right headers to prevent clickjacking
• WebSockets and web messaging check the origin and validate messages
• Browser storage (localStorage, sessionStorage) holds no tokens or sensitive data it does not need
• Third-party scripts are loaded from trusted sources, ideally with integrity checks

Why it matters: Modern single-page applications move a lot of logic into the browser, and the browser is fully under the attacker’s control. Third-party scripts are also part of the software supply chain risk that is third in the 2025 Top 10.

WSTG section 4.11. Related OWASP Top 10:2025 risk: A03 Software Supply Chain Failures and A05 Injection.

12. API testing

WSTG v4.2 covers GraphQL explicitly. Apply the same checks to REST and other APIs, which often skip the controls the web front end enforces.

• API endpoints enforce the same authentication and authorization as the web app
• Each object request checks that the caller may access that object
• GraphQL introspection is disabled in production unless it is needed
• Query depth, complexity and rate limits prevent resource exhaustion
• Responses return only the fields the client needs (no excessive data exposure)
• Old and undocumented API versions are retired or protected

Why it matters: APIs are where mobile apps, partners and front ends meet the data. An unprotected API can undo every control on the website.

WSTG section 4.12. Related OWASP Top 10:2025 risk: A01 Broken Access Control.

The OWASP Top 10:2025 mapped to this checklist

Use the Top 10 to group and explain findings in a report. The table shows where each 2025 risk is tested.

What changed from the 2021 Top 10

If your checklist was written for the 2021 list, update four things. Software Supply Chain Failures (A03) expands the old “Vulnerable and Outdated Components” category to the wider software ecosystem. Mishandling of Exceptional Conditions (A10) is new. Server-side request forgery is no longer a separate category; it is now part of Broken Access Control. Security Misconfiguration moved from fifth to second (OWASP Top 10:2025 introduction).

Reporting what you find

A finding is only useful if someone can fix it. For each issue, record:

1. A clear title and the affected URL, parameter or feature
2. Severity, using a standard scale such as CVSS, adjusted for the business impact
3. Steps to reproduce, with the requests and responses as evidence
4. The impact in plain language: what data or action is at risk
5. A specific remediation, with a link to the relevant OWASP guidance
6. Retest results once the fix is deployed

Group findings by Top 10 category in the summary so non-specialists can see the pattern. Handle the report as sensitive: it is a map to the weaknesses until they are fixed.

WSTG, ASVS and the Top 10: which to use

Sources: OWASP WSTG project, OWASP ASVS project and OWASP Top 10:2025, all read 16 October 2026. OWASP says WSTG version 5.0 is in development.

Where to practice legally

Never practice on a site you do not own. These are built to be tested:

• PortSwigger Web Security Academy is free and has interactive labs for most areas on this checklist, from access control to request smuggling. It is the best free starting point.
• OWASP Juice Shop is a deliberately insecure web shop you run on your own machine, with challenges that cover the Top 10.
• Damn Vulnerable Web Application (DVWA) is an older but still common practice app with adjustable difficulty, often used in courses.

For the tools themselves, our guide to web application penetration testing tools compares Burp Suite, OWASP ZAP and others.

Courses to learn web application testing

A checklist tells you what to test. A course shows you how. These three are current and cover the areas above; our full ranking is in the best penetration testing courses.

Zero To Mastery: Web Security & Bug Bounty

Web Security & Bug Bounty: Learn Penetration Testing by Aleksa Tamburkovski and Andrei Neagoie runs about 11.5 hours over 105-plus lessons and was last updated in October 2026. It starts from scratch and works through the common web vulnerability classes on practice targets. It is part of the ZTM membership, which also includes their ethical hacking courses.

See the ZTM Web Security course →

Udemy: Website Hacking / Penetration Testing (Zaid Sabih)

Zaid Sabih’s Website Hacking / Penetration Testing course had a 4.5 rating from 23,255 reviews and nearly 149,000 students on 16 October 2026, and was last updated in November 2025. It is the low-cost option, since Udemy discounts its courses often; check the price on the day.

See the course on Udemy →

Pluralsight: Web App Pen Testing path

Pluralsight’s Web App Pen Testing path groups 13 courses and 4 hands-on labs, about 20 hours in total, mapped to industry work roles. It suits learners who already have a Pluralsight subscription through work.

If you want a credential focused on web testing, PortSwigger’s Burp Suite Certified Practitioner exam is built around the same labs as the free Academy. You need an active Burp Suite Professional subscription to take it.

Frequently asked questions

What is a web application penetration testing checklist?

It is a list of the security checks a tester works through on a web application, grouped by area: information gathering, configuration, identity, authentication, authorization, sessions, input handling, errors, cryptography, business logic, client-side code and APIs. The most widely used basis is the OWASP Web Security Testing Guide, whose stable version is 4.2.

Is the OWASP Top 10 a pentest checklist?

No. The Top 10 is an awareness list of the most important risk categories. It is a useful floor and a good way to report findings, but it does not tell you what to test. Testers build their checklist from the Web Security Testing Guide and use the Top 10 to group and explain results.

Do I need permission to run these checks?

Yes. Run them only on applications you own or have written permission to test, within an agreed scope. Testing a site without authorization can be a crime in many countries, including under the US Computer Fraud and Abuse Act. Use deliberately vulnerable practice apps to learn.

What is the difference between the WSTG and ASVS?

The Web Security Testing Guide (WSTG) describes how to test an application. The Application Security Verification Standard (ASVS) lists the security requirements an application should meet, at three levels of rigor. Many teams use ASVS to define what “secure enough” means and the WSTG to check it. The current ASVS is version 5.0.0.

Has OWASP released WSTG version 5?

Not yet. On 16 October 2026 the OWASP project page listed version 4.2 as the latest release and said version 5.0 is in development. Version 4.2 already includes API testing (GraphQL), cloud storage and subdomain takeover checks.

What tools do I need for this checklist?

An intercepting proxy is the core tool: Burp Suite Community Edition (free) or OWASP ZAP. Most checks are manual and use the proxy to read and repeat requests. Scanners help with coverage but miss business-logic and authorization flaws. Our web application pentesting tools guide compares the options.

Where can I practice web application testing legally?

PortSwigger’s Web Security Academy is free and has hands-on labs for most of the areas on this checklist. OWASP Juice Shop is a deliberately insecure app you run on your own machine. Both are designed to be attacked, so you can practice without legal risk.

Related guides

• Penetration testing methodology: 7 phases and 6 standards
• Best web application penetration testing tools
• Network penetration testing checklist
• Best penetration testing tools
• Cyber security trends for 2026
• Common website hacking techniques and what stops each one
• Best penetration testing courses
• Best bug bounty courses
• Is ethical hacking legal?