Pentest checklist for a web application (OWASP WSTG)

A pentest checklist for a web application is an ordered list of test cases, grouped by area, that a tester works through to find vulnerabilities in a running app and its APIs. The most widely used backbone is the OWASP Web Security Testing Guide (WSTG), which splits web testing into twelve categories. This page turns those categories into checks you can run, assign and tick off in 2026.

What is a web application penetration testing checklist?

A web application penetration testing checklist is a written set of security test cases, each with a clear pass or fail result. It tells a tester what to try and a reader what was covered.

A checklist is not a penetration test on its own. It is the plan. The test is trying each item against your running app and proving what you find. Our full web application penetration testing guide explains the phases around it, and the VAPT checklist covers the project steps before and after testing.

WSTG v4.2 is the stable release. It numbers every test, such as WSTG-ATHN-03 for a weak lock-out mechanism, so a checklist, a report and a ticket can all point to the same item. We use those IDs below. OWASP also keeps a WSTG v4.2 checklist spreadsheet for tracking progress; the pass criteria below are what it leaves out.

Why does a web app pentest need a checklist in 2026?

A checklist keeps testing complete and repeatable, and the data says web flaws are still how attackers get in. The 2026 Verizon Data Breach Investigations Report (DBIR), which covers incidents from 1 November 2024 to 31 October 2025, found that software vulnerabilities are now the most common starting point, at 31% of breaches, ahead of stolen passwords.

The same report puts ransomware in 48% of breaches. Separately, the CISA Known Exploited Vulnerabilities catalogue listed 1,734 vulnerabilities when we read it on 7 October 2026, each one already used in real attacks.

None of that proves your app has a flaw. It explains why buyers and auditors ask what was tested, and a checklist answers: these items, these dates, this evidence.

It does three jobs. Before you buy a test, it shows what applies to your app. When quotes arrive, it exposes thin ones: an "OWASP-based" proposal that never mentions authorisation or business logic needs questions (see how to choose a penetration testing company). And your developers can clear the cheap items first, so paid hours go on the hard problems.

What a checklist does not do

It misses flaws outside its items, usually your business rules. Treat it as a floor and add cases for your pricing, approvals, limits and tenant boundaries.

What do you need ready before testing starts?

You need a signed scope, a test environment, working accounts and a named contact. Most delays come from missing access, not from testing.

Pre-test readiness table

Choose a test mode

The same checklist runs at three depths. In black-box testing the tester has only a URL. In grey-box testing they get accounts and documents. In white-box testing they also read the source code. Deeper access means fewer guesses. We compare them in black box vs grey box vs white box.

Which OWASP WSTG categories should the checklist cover?

It should cover all twelve test categories in WSTG v4.2, sections 4.1 to 4.12. Skipping one is how coverage quietly shrinks.

WSTG v4.2 categories at a glance

Across sections 4.1 to 4.12, v4.2 numbers 97 tests. The counts mislead if you plan time by them: Authorization has only four tests and Business Logic nine, yet those two need the most judgement, because no tool knows which account should see which record. The OWASP Top 10 is different: it ranks common risk categories, while the WSTG tells you how to test. Use the Top 10 to set priorities and the WSTG to build the list.

The web application pentest checklist, category by category

Each table below lists checks, the matching WSTG test, and what a pass looks like. Work through them in order, because earlier results (endpoints, roles, parameters) feed later ones. Mark each item pass, fail, not applicable or not tested, and never leave it blank.

1. Information gathering and configuration (INFO, CONF)

Start by mapping what exists. Forgotten hosts, old backups and open admin pages are cheap for an outsider to find and often serious.

Evidence to keep

A host and route inventory, screenshots of exposed pages, and the response headers for each fingerprinted component. The inventory also becomes the scope for the retest.

2. Identity and authentication (IDNT, ATHN)

These tests ask whether someone can become an account that is not theirs. Focus on sign-up, sign-in, reset and recovery, because attackers use them at scale.

3. Authorisation and access control (ATHZ)

Authorisation is where most serious web findings live. Broken access control is number one in the OWASP Top 10:2025. The A01:2025 page reports 40 mapped CWEs, an average incidence rate of 3.74% and a maximum of 20.15%, across 1,839,701 occurrences, and says 100% of the applications tested had some form of broken access control.

The test idea is simple: see what one signed-in account can reach that it should not, such as another customer's records or admin actions. It needs two accounts per role and two tenants. Details are in the access control testing checklist and the IDOR checklist.

What to record

For every cross-account finding, keep the two account names, the exact request, the response that shows the other account's data, and the line of code that skipped the ownership check if you have source access. A fix should add the check where the data is read, not only in the controller.

4. Session management (SESS)

Sessions are what keep a user signed in, so weak sessions undo strong passwords. The OWASP Session Management Cheat Sheet wants Secure and HttpOnly on session cookies, SameSite=Strict where possible (Lax otherwise), and a fresh session ID whenever the privilege level changes.

Evidence to keep

The cookie header exactly as issued, and any replayed request that still worked after logout or timeout.

5. Input validation and injection (INPV)

Input validation covers anything a user can send that the app then trusts. Test every parameter: query strings, JSON bodies, headers, cookies, file names and uploaded content. The well-known classes are SQL injection, cross-site scripting, command injection, template injection and server-side request forgery.

Follow each input from the field to the query, template or command that uses it. A harmless proof, such as a version string, is enough evidence.

6. Error handling and cryptography (ERRH, CRYP)

Errors and weak crypto rarely cause a breach alone, but they confirm other bugs and expose data.

7. Business logic (BUSL)

A business logic flaw follows the rules of your code but breaks the rules of your business. No scanner knows your rules, so a person who understands the product has to test them. WSTG lists nine tests, BUSL-01 to BUSL-09. Our business logic testing checklist goes further.

Evidence to keep

The normal flow, then the altered one, with the money, quota or state change shown on both. Business impact is the point here.

8. Client-side testing (CLNT)

Client-side checks look at what the browser is made to do. A Content-Security-Policy is not a numbered v4.2 test, so add a header review as your own item.

9. API testing (APIT)

What WSTG 4.12 covers

Most modern web apps are thin screens over an API, so test the API directly, not only through the UI. WSTG 4.12 covers GraphQL. For REST, apply the same categories above to every route in your specification, pair them with the OWASP API Security Top 10 (2023), and read the API security testing guide.

How do you run the checklist in a sensible order?

Run it in four passes: map, sign in, probe, then chain. Each pass feeds the next.

1. Map (INFO, CONF): hosts, routes, versions, exposed files.
2. Sign in (IDNT, ATHN): accounts, login, reset, lock-out.
3. Probe (ATHZ, SESS, INPV, BUSL, CLNT, APIT, ERRH, CRYP): every category above.
4. Chain: combine low findings into real impact and rate them.

Allow time for the chain pass. A leaked internal route, a missing ownership check and a verbose error can each look minor alone. Together they may expose a whole customer table. Rate the chain by what it allows. Our post on reading a penetration test report shows how.

Which checks come first when time is short?

Start with cross-account access, then sign-in and reset flows, then business logic on money or data features. These are the areas where a tool cannot know your rules, so a person has to spend the hours. The OWASP Top 10:2025 still ranks broken access control first, which supports this order.

A one-day priority order

This is a triage order, not a replacement for the full list. Anything you skip goes in the sheet as "not tested", with a reason.

What evidence should each checklist item leave behind?

Each item should leave a result, a date, a tester and proof. Without proof, a pass means little and a fail cannot be fixed or retested. The table shows the minimum. Map each fail to a CWE and keep severity apart from confidence; our post on how to read a finding shows both.

Evidence by result

How do you turn the checklist into fixes and a retest?

Turn each failed item into a ticket with the evidence attached, an owner and a due date, then retest the exact failing request after the fix. A new general scan does not prove the old flaw is closed; re-running the original exploit does. This is a closed-loop retest. Then try two variants, such as another HTTP method or another account, because partial fixes are common.

Add a regression test

For each cross-account or logic fix, add an automated test to your own suite that repeats the failing request and expects a refusal. Plan this in the remediation process rather than leaving it to memory.

Which checks can be automated and which need a person?

Header checks, TLS settings, known component versions and many injection patterns can be automated, and a DAST tool is good at them. Access control and business logic need account context and product knowledge, so they need either a skilled tester or tooling that works with real signed-in accounts. See DAST, SAST and IAST compared for what each tool type finds, and what we do not do for our own limits.

Cyberlop finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting. It checks business-logic flaws and cross-account access, and in white-box mode a finding can point to the file and line. It reports only what it actually exploited, and proves a fix by re-running the exact exploit. See how it works and what a finding looks like. If your code must stay inside your network, private scanning runs there.

What mistakes make a checklist useless?

• One account only. Cross-account flaws cannot be seen with a single login.
• Testing staging that differs from production. Feature flags, WAF rules and data differ, so results do not carry over.
• Ticking boxes without proof. A tick with no request and response cannot be audited.
• Ignoring the API. The UI hides routes that the API still serves.
• No retest. A fix that was never replayed is a hope, not a result.

To decide what runs every release and what runs once a year, see continuous penetration testing.