Web Application Security Testing Checklist Template

What the Web Application Security Testing Checklist Covers

1. 1
   Phase 1

   Phase 1: Scope & Rules of Engagement

   6 tasks

   Agree what will be tested, where, with which accounts and inside which window, and get written approval before any test traffic is sent. Answer the API and change questions first: they add the matching tests. Every due date counts from the day the test window starts.

   • Record the application, the release and who is involved — the application and version under test, the release it is for, the day the test window starts, which every due date counts from, the planned release date, and the security champion, developer lead, QA lead and security lead for this round
   • Choose the target ASVS level and the test areas — the OWASP ASVS level the application aims for, set from its risk, and the WSTG categories this round covers, focused on what the release adds or changes
   • Set up the test environment and test accounts — a production-like environment running the release candidate, at least one account per role and two accounts at the same role to test access between users, test data with no real personal data, and an expiry date on every account
   • Agree what is out of scope and the test window — production, third-party services, other customers’ data and load or denial-of-service tests unless agreed, with the window’s end date and the hours testing may run
   • Tell the people who need to know — operations, whoever watches the monitoring alerts and the hosting provider where its terms ask for notice, with a contact who can stop testing if the service is affected
   • Get written approval to test — from the application owner, covering the scope, environment, accounts and window above; no testing starts without it
2. 2
   Phase 2

   Phase 2: Information Gathering & Configuration

   6 tasks

   Map the application before you test it, then check how it is deployed. Use the application as each role through an intercepting proxy. WSTG-INFO and WSTG-CONF cover these areas.

   • Map the application’s entry points and execution paths — every page, form, parameter, header, cookie and upload the release adds or changes, found by using the application as each role through an intercepting proxy (WSTG-INFO-06, -07)
   • Fingerprint the web server, framework and components — the server, frameworks and libraries in use and their versions, checked against the dependency list and known vulnerabilities (WSTG-INFO-02, -08, -09)
   • Check what the application gives away — page comments, metafiles such as robots.txt, error pages and search engine results that reveal paths, versions or internal names (WSTG-INFO-01, -03, -05)
   • Check platform configuration, HTTP methods and HSTS — default and sample files removed, only the HTTP methods the application needs, and Strict-Transport-Security on HTTPS responses (WSTG-CONF-02, -06, -07)
   • Look for exposed admin interfaces, backups and old files — admin consoles, backup copies, old versions and unreferenced files reachable from the web (WSTG-CONF-04, -05)
   • Check file permissions, cloud storage and subdomains — files and storage buckets readable only by those who need them, and no subdomain pointing at a service you no longer control (WSTG-CONF-09, -10, -11)
3. 3
   Phase 3

   Phase 3: Identity, Authentication & Access Control

   6 tasks

   Broken access control is first in the OWASP Top 10:2025. Test every role with its own account, and test one user’s access to another user’s data. WSTG-IDNT, -ATHN, -ATHZ and -SESS cover these areas.

   • Test role definitions, registration and account provisioning — each role has only the access it needs, and sign-up or account creation cannot be used to gain a higher role (WSTG-IDNT-01 to -03)
   • Test login, lockout and account enumeration — credentials sent only over HTTPS, no default accounts, a lockout or throttle on repeated failures, and no way to tell which usernames exist (WSTG-ATHN-01 to -03, WSTG-IDNT-04)
   • Test password reset, password change and multi-factor authentication — a reset link that expires and works once, the current password needed to change it, and no route that skips the second factor (WSTG-ATHN-04, -09, -10)
   • Test authorisation between roles and between users — every function and record checked on the server: a lower role cannot reach admin functions, and one user cannot read or change another user’s records by changing an ID (WSTG-ATHZ-02 to -04)
   • Test session handling — cookies set with Secure, HttpOnly and SameSite, a new session ID after login, sessions that end at logout and after the timeout, and protection against cross-site request forgery (WSTG-SESS-01 to -03, -05 to -07)
   • Run deeper tests on the authentication changes — every changed sign-up, login, reset, multi-factor or single sign-on path tested with each role, including attempts to skip a step, and checked against the ASVS 5.0.0 chapters V6 Authentication, V7 Session Management and, for single sign-on, V10 OAuth and OIDC
4. 4
   Phase 4

   Phase 4: Input Validation & File Uploads

   5 tasks

   Test every input the release adds or changes, on the server side, as each role. Record which areas you covered; the WSTG gives the method for each test. WSTG-INPV covers these areas, and WSTG-BUSL the file uploads.

   • Test for cross-site scripting — reflected and stored, in every field that is shown back to a user, including admin screens that display what users entered (WSTG-INPV-01, -02)
   • Test for SQL, NoSQL and other injection — every parameter that reaches a database, a directory, an XML parser, a template engine or an operating-system command (WSTG-INPV-05 to -12, -18)
   • Test for server-side request forgery — every feature that fetches an address or file a user supplies, such as imports, webhooks and link previews (WSTG-INPV-19)
   • Test HTTP parameter handling and host headers — duplicate parameters, unexpected HTTP methods and a changed Host header, including in the links the application emails (WSTG-INPV-03, -04, -17)
   • Test file uploads — file type, size and content checked on the server, uploads stored where they cannot run as code, and unexpected or malicious files refused (WSTG-BUSL-08, -09)
5. 5
   Phase 5

   Phase 5: Errors, Cryptography, Business Logic & Client-Side

   6 tasks

   These are the areas automated scanners verify least. Business logic tests need someone who knows how each feature is meant to work. WSTG-ERRH, -CRYP, -BUSL and -CLNT cover these areas.

   • Test error handling — errors show a generic message with no stack trace, query or version, and the application fails safely when something unexpected happens (WSTG-ERRH-01, -02)
   • Test transport security and encryption — TLS on every connection with current protocols and ciphers, no sensitive data sent over unencrypted channels, and no weak encryption where the design uses it (WSTG-CRYP-01, -03, -04)
   • Test the business logic of the changed features — steps that cannot be skipped or repeated, limits that cannot be exceeded, prices, quantities and states that cannot be changed in the request, and timing that cannot be abused (WSTG-BUSL-01 to -07)
   • Test client-side behaviour — DOM-based cross-site scripting, client-side redirects, cross-origin resource sharing, clickjacking protection and what the browser stores (WSTG-CLNT-01, -04, -07, -09, -12)
   • Run deeper tests on the payment changes — amounts, currency and order totals checked on the server, payment steps that cannot be skipped or replayed, payment provider callbacks verified, and no card data stored or logged by the application
   • Check security logging — logins, failed logins, access denials and admin actions logged with enough detail to investigate, and no passwords, tokens or session IDs in the logs
6. 6
   Phase 6

   Phase 6: API Tests

   5 tasks

   Shown when the application has an API. The OWASP API Security Top 10 (2023 edition) lists the commonest API risks; WSTG v4.2 has one API test, for GraphQL (WSTG-APIT-01).

   • List every API endpoint the release adds or changes — from the API description or the proxy log, with the method, the roles allowed to call it and the data it returns, so no endpoint is missed
   • Test object-level and property-level authorisation — one user cannot read or change another user’s object by changing its ID, or read or set properties their role should not see (API1:2023, API3:2023)
   • Test function-level authorisation and API authentication — admin and internal endpoints refuse ordinary users, and every endpoint needs a valid token or key that expires (API2:2023, API5:2023)
   • Test rate limits and resource use — limits on requests, page sizes, upload sizes and expensive operations, so one client cannot exhaust the service or automate a sensitive business flow (API4:2023, API6:2023)
   • Test GraphQL if the API uses it — introspection, query depth and batching limits, and authorisation on every field (WSTG-APIT-01)
7. 7
   Phase 7

   Phase 7: Findings, Fixes & Retest

   6 tasks

   Log each finding as it is found, rate it, give it an owner and a fix date, and retest every fix on a new build. The task for critical or high findings appears only when one is still open after the retest.

   • Log each finding with its severity and evidence — a reference, title, affected URL or endpoint, WSTG test ID, severity (Critical, High, Medium, Low or Informational) and the steps to reproduce, with passwords and personal data masked
   • Agree the severity of each finding — how easy it is to exploit, the access it needs and its impact on this application, rated with one written scheme, so the release decision rests on agreed ratings
   • Assign an owner and a fix date to each finding — in the team’s issue tracker, with critical and high findings fixed before release unless the security lead accepts the risk in writing
   • Fix the findings and add tests that would catch them again — each fix reviewed like any other change, with an automated test added wherever one can catch the same flaw in a future build
   • Retest every fix on the new build — the original test repeated on the release candidate, with a finding closed only when it no longer reproduces
   • Decide how each open critical or high finding is handled — fix and retest it before release, or record a risk acceptance with the reason, a compensating control, an expiry date and who accepted it
8. 8
   Phase 8

   Phase 8: Release Decision & Close

   5 tasks

   The security lead records the release decision. Nothing after that step can be completed until a decision is recorded.

   • Write the test summary — the scope and ASVS level, the WSTG areas covered and not covered, findings by severity and their status, and limits such as untested areas or missing accounts
   • Security lead records the release decision — Release, Release with accepted risks or Do not release, based on the summary, the open findings and any risk acceptances
   • Pass the decision to the release manager — the decision, the summary and any accepted risks attached to the release record, so the go/no-go has the security result
   • Remove test accounts and test data — every test account disabled, test data, tokens and keys deleted, and any temporary access or firewall changes made for the test removed
   • Carry the lessons into the next round — findings that keep coming back, tests to automate, changes to this checklist and training needs, with the date of the next round