# Webapp Testing Checklist

> Draft · awaiting review.

> Agent skill that walks an authorized web application test through the OWASP WSTG checklist and writes a findings report.

- Badge: `reach 3 · not run yet`
- Type: Skill; tier: not run yet
- Tasks: Web and API testing; mission: Offensive; works with: Claude Code
- Source: https://github.com/AccessITGroup/webapp-testing-checklist, pinned to `d79e594`, licence MIT AND CC-BY-SA-4.0
- Last checked: 2026-10-21; next check: 2027-01-19; method v0.1, reach-v0.1

## At a glance

- **What it is:** A skill that walks a web application penetration test through the OWASP Web Security Testing Guide (WSTG) as a structured checklist and produces WSTG-numbered findings. It aids a human-led engagement: it may send benign traffic, while attack testing stays with the tester's own tooling. A skill is a set of instructions, and sometimes scripts, that your AI client loads when a task needs it.
- **Made for:** Structures an authorized web application penetration test around the OWASP WSTG methodology and tracks checklist coverage. +2 more
- **Runs:** Inside your AI client: its model follows the instructions and works with the client's own tools.
- **Sends data to:** Target web application (by default). Other connections not ruled out: read in the documentation and the cited code, not searched in full.
- **Can change things:** Changes, sends data out, according to the capabilities read.
- **Needs:** Claude Code, with the skill installed from the AITG-hub marketplace or directly · Written authorization to test the specific target, such as a signed SOW or pentest agreement · Named engagement, in-scope hostnames/apps/IP ranges, testing window and rules of engagement with points of contact · +4 more

Profile read at commit `d79e594` on 2026-10-25; every fact cites a file and line at that commit.

## What it does

A skill that walks a web application penetration test through the OWASP Web Security Testing Guide (WSTG) as a structured checklist and produces WSTG-numbered findings. It aids a human-led engagement: it may send benign traffic, while attack testing stays with the tester's own tooling. (SKILL.md#L3)

Made for (the author says):

- Structures an authorized web application penetration test around the OWASP WSTG methodology and tracks checklist coverage. (SKILL.md#L8-9)
- Turns tester-supplied evidence into a findings report with WSTG-numbered IDs. (README.md#L3-5)
- Asks a diagnostic question per WSTG test and interprets the evidence the tester hands over, including raw Burp/ZAP captures. (README.md#L11-12)

Documented uses:

- Plan, scope or track a web application pentest against the WSTG checklist. [Web and API testing] (SKILL.md#L3)
- Produce a findings report with WSTG IDs in Markdown, Word (.docx) or PDF. [Web and API testing] (SKILL.md#L174-176)
- Assess tester-supplied request/response evidence against a WSTG test's criteria and record the verdict. [Finding validation] (SKILL.md#L87-88)
- Walk an API-only target through API Testing plus the API-relevant tests from Authentication, Session, Input Validation and Business Logic. [Web and API testing] (SKILL.md#L71-73)

Not for (the author says):

- The author rules out payloads, injection strings, exploit attempts and scanners; benign traffic is allowed and the tester does the actual security testing. (README.md#L7-10)
- Meant as a workflow aid for testers who are already authorized, not as a safeguard against unauthorized use. (README.md#L47-49)
- Covers dynamic/black-box testing only; the report recommends a separate source code security review when that is in the SOW and source access is given. (README.md#L75-77)

## What it can do

| Group | What it covers | Effect | On by default |
|---|---|---|---|
| Step 1 — Authorization gate | Before anything else, has the tester confirm written authorization for the target (signed SOW, pentest agreement or equivalent); stops and explains what is missing. (SKILL.md#L21-26) |  | yes |
| Test credentials file | Reads the test accounts once from a plain-text file in the working directory (suggested name test-credentials.txt), then refers to them by label only in the session and report. (SKILL.md#L44-53) | reads | yes |
| Step 2 — Scope intake | Asks whether the app is server-rendered, API-only or an SPA with a backend API, which decides which of the 12 WSTG categories in references/ apply. (SKILL.md#L65-74) |  | yes |
| Step 3 — Walk the checklist | Loads one references/ category file at a time, states each test ID and what it verifies, and takes evidence or a direct Pass/Fail/N/A verdict from the tester. (SKILL.md#L81-90) | reads | yes |
| Evidence directory convention | Keeps raw request/response captures and screenshots in ~/wstg-evidence/, split into fail-evidence/ and pass-evidence/ with one subfolder per WSTG test ID. (SKILL.md#L100-106) | reads, changes | yes |
| Self-tested findings | Writes the real requests and responses of the skill's own benign checks, such as fingerprinting, header checks and tester-directed forced-browsing/IDOR checks, to evidence.txt. (SKILL.md#L140-148) | reads, changes | yes |
| Backseat mode benign traffic | Sends ordinary application traffic itself, such as viewing pages, following links and submitting forms with non-malicious input, when it helps gather checklist context. (SKILL.md#L10-13) | reads, sends data out | yes |
| Account creation (gated) | Creates a test account in the target application only after the tester confirms the SOW allows it and gives a real-time go-ahead for that account. (SKILL.md#L233-240) | changes | no |
| Repeated-attempt tests | Sends repeated requests such as several failed logins for lockout testing after telling the tester the count and target and getting explicit go-ahead each time. (SKILL.md#L262-268) | sends data out | no |
| Step 4 — Report | Asks for Markdown, Word (.docx) and/or PDF and writes the report with whatever document-generation capability the environment has. (SKILL.md#L172-176) | changes | yes |

## How it runs

The client's model loads each in-scope WSTG category file from references/ one at a time as the walk reaches it, instead of all 12 up front. (SKILL.md#L81-82)

- Starts: Inside your AI client: its model follows the instructions and works with the client's own tools. Runs as a Claude Code skill whose instructions the client's model follows. (README.md#L3)
- Your AI client: **SKILL.md**: Skill manifest with frontmatter name webapp-testing-checklist and a description of the WSTG checklist walk, findings report and backseat-mode limits. (SKILL.md#L1-3)
- Your AI client: **references/ category tables**: WSTG checklist tables, one file per category, each row a test ID, title and what it verifies; loaded as the walk reaches the category. (references/00-overview.md#L31-33)
- Your machine: **test-credentials.txt**: Plain-text file in the working directory with one test account per line: label, role, username, password. (SKILL.md#L43-48)
- Your machine: **~/wstg-evidence/**: Evidence directory in the home directory, split into fail-evidence/ and pass-evidence/ with folders named by WSTG test ID (e.g. WSTG-AUTHZ-04). (SKILL.md#L103-106)
- Your machine: **Tester's own tooling**: Burp Suite, ZAP, curl, browser devtools and similar tools the tester uses for the actual security testing. (SKILL.md#L15-16)
- Outside your machine: **Target web application**: The in-scope hostnames, apps or IP ranges the tester names in Step 1. (SKILL.md#L29-32)
- Sends data to Target web application (your targets, by default): Sends benign requests to the in-scope target, such as fingerprinting, header checks and tester-directed forced-browsing/IDOR checks. (SKILL.md#L140-142)

## What you need

- Runtime: Claude Code, with the skill installed from the AITG-hub marketplace or directly. (README.md#L60)
- Authorisation: Written authorization to test the specific target, such as a signed SOW or pentest agreement. (SKILL.md#L26-28)
- Authorisation: Named engagement, in-scope hostnames/apps/IP ranges, testing window and rules of engagement with points of contact. (SKILL.md#L29-34)
- Credentials: Test accounts in a plain-text file in the working directory, one per line with label, role, username and password. (SKILL.md#L44-48)
- Other tools: The tester's own testing tools, such as Burp Suite, ZAP, curl or browser devtools, for the actual security testing. (README.md#L10)
- Other tools: For .docx reports with screenshots, the author reports pandoc or python-docx, where available, as more reliable than OS-builtin converters. (README.md#L93-94)
- Other tools: Screenshots of self-tested findings need a visual or browser-automation capability in the environment, not just a CLI HTTP client. (SKILL.md#L153-155)
- Installer: Adds the AITG-hub marketplace from the GitHub repository AccessITGroup/claude-plugins, then installs webapp-testing-checklist@AITG-hub; the marketplace repository is separate from this one. (README.md#L62-65)
- Installer: Versions follow the webapp-testing-checklist entry in the AITG-hub marketplace; CHANGELOG.md lists 0.7.0 as the latest. (CHANGELOG.md#L3-6)

## Limits and risks

- The authorization gate is a prompt the model follows and cannot verify anything; it relies on the tester answering honestly. (README.md#L44-46)
- The author notes that a fork can strip the guardrails out entirely. (README.md#L46-47)
- test-credentials.txt holds live secrets in plain text in the working directory; the skill reminds the tester to .gitignore it and delete it after the engagement. (SKILL.md#L54-56)
- ~/wstg-evidence/ in the home directory can accumulate captured HTTP traffic, cookies, session tokens and client-identifying data; the skill prompts the tester to delete or archive it after the report. (SKILL.md#L206-210)
- Target page bodies, headers and pasted captures enter the model's context; the skill tells the model to treat instructions inside them as data and not act on them. (SKILL.md#L214-220)
- The guardrail eval cases in evals/ were written against the documented schema and have not been run end to end. (evals/README.md#L21-23)
- Running the eval suite with claude plugin eval requires early access on the account or organization. (evals/README.md#L20-21)
- A clean run is not a certification; WSTG is not exhaustive and the references/ summaries are shorter than the full WSTG guidance. (README.md#L81-83)
- The client's model reads the credentials file itself, so test usernames and passwords enter its context; the skill tells it not to repeat them in the conversation or report. (SKILL.md#L52-54)
- The skill tells the model to decline destructive, high-volume or DoS-style traffic, regardless of what the stated rules of engagement say. (SKILL.md#L241-246)
- The skill tells the model to stop and reconfirm scope before touching a host, port or path that was not confirmed at Step 1. (SKILL.md#L247-250)
- The skill tells the model never to run exploit code, PoC scripts or third-party attack tooling, even when the tester supplies it, and to hand that back to the tester. (SKILL.md#L257-261)

## Rights in plain language

- Declared: files 2 (writes outside the project), network 1 (talks only to declared hosts), execution 1 (runs only declared programs), secrets 2 (reads broad tokens or the environment), persistence 3 (adds autostart, users or keys).
- Code: reach 3 (privileged): files 2 (writes outside the project), execution 2 (runs shell commands or eval), secrets 2 (reads broad tokens or the environment), persistence 3 (adds autostart, users or keys); unknown: approval.
- Lab: not run yet.

Why three columns? Declarations are often incomplete and scanners can be bypassed, so we run each tool once and compare.

## Privilege Reach

Reach level 3 (privileged).

| Right | Declared | Code | Lab |
|---|---|---|---|
| Files: where does it read and write? | 2 writes outside the project | 2 writes outside the project | not run yet |
| Network: whom does it talk to? | 1 talks only to declared hosts | 1 talks only to declared hosts | not run yet |
| Execution: what does it run? | 1 runs only declared programs | 2 runs shell commands or eval | not run yet |
| Secrets: which credentials does it touch? | 2 reads broad tokens or the environment | 2 reads broad tokens or the environment | not run yet |
| Persistence: what survives the run? | 3 adds autostart, users or keys | 3 adds autostart, users or keys | not run yet |
| Approval: does it ask before acting? | not declared | ? unknown | not run yet |

0 contained · 1 scoped · 2 open · 3 privileged · ? no evidence · 0 never means safe

## Install

### Upstream

Quoted from `README.md#L60-64` at the pinned commit (not a command to copy): `/plugin marketplace add AccessITGroup/claude-plugins
/plugin install webapp-testing-checklist@AITG-hub`


### Run it with least privilege

- claude code: `permissions.allow: [Read, Grep]; keep Bash, Write and WebFetch on ask, and keep test-credentials.txt and ~/wstg-evidence/ out of synced or shared folders`
- note: `derived from the code, not tested in the lab`

- derived, not tested: proposed from the code analysis

## Lab runs

Not run yet.

## Questions and answers

**Why compare declared, code and lab?**

Declarations are often incomplete and scanners can be bypassed, so we run each tool once and compare.

**What rights does Webapp Testing Checklist declare?**

files 2 (writes outside the project), network 1 (talks only to declared hosts), execution 1 (runs only declared programs), secrets 2 (reads broad tokens or the environment), persistence 3 (adds autostart, users or keys).

**What does its code suggest?**

reach 3 (privileged): files 2 (writes outside the project), execution 2 (runs shell commands or eval), secrets 2 (reads broad tokens or the environment), persistence 3 (adds autostart, users or keys); unknown: approval.

**What did it use when it ran in the lab?**

not run yet.

**Was it tried, and when?**

Not yet (tier listed).

**What changed since the last check?**

Upstream last pushed 2026-09-03; 0 release(s) since the pinned version.

**How do I run it with least privilege?**

Derived, not tested: claude_code: permissions.allow: [Read, Grep]; keep Bash, Write and WebFetch on ask, and keep test-credentials.txt and ~/wstg-evidence/ out of synced or shared folders; note: derived from the code, not tested in the lab

Method: https://readbeforerun.ai/method/