CMWAP Pentest Plan — Template

8-hour exam. Fill this in and send it to your examiner before the plan deadline in your brief. Nothing here is pre-filled — the budget arithmetic is the exercise. No edits after submission; deviations go in the change log. Source for [TEMPLATE] CMWAP Pentest Plan - 010.pdf / .docx. The XSS Rat · CMWAP.

Pentest Plan — Template

Eight hours. You decide how many of them are testable, and which endpoints get them.

How this is used. Fill it in and send it to your examiner before the plan deadline in your brief. Not a draft — the finished plan. Everything after that is graded against what you wrote.

No edits after submission. If something changes, you do not rewrite the plan — you add a line to the change log and carry on.

Nothing in this template is filled in for you. The budget is the plan. Working out your own numbers is the exercise — a plan you did not do the arithmetic for is a plan you cannot defend in the debrief.

Field	Value
Candidate
Target / engagement
Window opens (T+0:00)	date + clock time + timezone
Plan due	from your brief — write the real clock time, not “T+…”
Report + debrief due
Authorization	what permits this engagement, and any published rules that still apply
Plan version	v1.0

1 · Objective (suggested 0:00 – 0:10)

One sentence. Start with a verb, name a consequence. In an eight-hour window you are answering one question well, not surveying an application.

A consequence is something the client feels — money, data, trust, downtime. “Test the application for vulnerabilities” is an activity, not a consequence.

2 · Time budget (suggested 0:10 – 0:20)

Do this before the endpoint table. You cannot decide what to defer until you know what you can afford. Every number below is yours to set and yours to defend.

Fixed costs — what the window owes before you test anything

Fixed cost	Hours	Why that much
Total window	8.00	given
Writing and sending this plan	−
Report — ring-fence it, never borrow from it	−
Debrief video: record, review, upload	−
Setup, access, evidence admin	−
TESTABLE TIME = total − fixed costs	h	= min

Write the minutes figure down. Section 3 has to add up to it.

How the testable time is spent

Wall clock	Block	Budget	What must be true when it ends
	Plan — write and send		submitted; timer stops
	Recon and mapping
	IN · MUST endpoints
	IN · SHOULD endpoints
	Verify and capture proof
	Report		ring-fenced; not testing time
	Debrief video
	Submit and buffer
Testing subtotal — recon + MUST + SHOULD + verify		min	must equal your testable time above

3 · Endpoint inventory and disposition (suggested 0:20 – 0:35)

One row per endpoint or function — not per feature. Every row gets a WSTG ID, a disposition, and a reason a stranger would accept. This table is your scope statement.

IN — authorized, relevant, and it fits your budget. You will test it. / OUT — not authorized, or not yours to touch. Never tested, at any budget. / DEFERRED — authorized and relevant, but it does not fit your testable time. Named, not silently dropped.

#	WSTG ID(s)	Budget
1	WSTG-	min
2	WSTG-	min
3	WSTG-	min
4	WSTG-	min
5	WSTG-	min
6	WSTG-	min
7	WSTG-	min
8	WSTG-	min
9	WSTG-	min
10	WSTG-	min
11	WSTG-	min
12	WSTG-
13	WSTG-
14	WSTG-
15	WSTG-
16	WSTG-
17	WSTG-
18	WSTG-
IN minutes — must equal your MUST + SHOULD budget from section 2		min

The arithmetic is the discipline. Add up the Budget column for your IN rows. If the total is larger than the MUST + SHOULD figure you set in section 2, you do not have a plan — you have a wish. Move rows to DEFERRED until the two numbers match. An examiner can forgive a small scope; nobody forgives a plan that was never achievable.

4 · Deferred register (suggested 0:35 – 0:40)

Deferred is a decision, not a gap. Each row names what would have to be true for you to pull it forward — that sentence is what you say in the debrief when you are asked what you left on the table, and it is what turns mid-engagement curiosity into a logged decision instead of drift.

Deferred item	WSTG ID(s)	Why it did not fit	What would pull it forward

5 · Rules of engagement (suggested 0:40 – 0:45)


Environment (prod / staging / lab)
Accounts issued to you / created by you
Rate limit / thread cap you will hold to
Actions you will NOT take (destructive, DoS, spam)
Out-of-band listener
Evidence: what you capture, where it is stored
Escalation on a critical — who, how fast
Abort criteria — what makes you stop and report
The line you will not cross	the finding you would confirm but deliberately not develop, and why
Tools declared, with tier (incl. AI)
Time budgeted to verify anything a tool or AI produced

6 · Thesis, risks and change log

Thesis

Which IN row do you believe holds the serious finding, and why? Test it first. A thesis that turns out wrong is fine — say so and re-plan on the record.

Assumptions and risks

The right-hand column is the useful one: an assumption with no stated fallback is just a hope.

Assumption or risk	What you do if it turns out false

Change log — starts empty, stays open the whole window

Every deviation, with its cost in minutes and what you cut to pay for it. In an eight-hour window an unlogged forty-minute overrun is a large slice of your testable time, unaccounted.

T+	What changed	Cost	Paid for by

Before you send it — 60-second check

☐ Objective is one sentence and names a consequence ☐ Fixed costs subtracted; testable minutes written down / ☐ Every endpoint row has a WSTG ID ☐ Every row is IN, OUT or DEFERRED — none blank / ☐ IN minutes equal your MUST + SHOULD budget ☐ Every deferred row has a trigger / ☐ Abort criteria and the line you will not cross are written ☐ Thesis names one IN row / ☐ Change log present and empty ☐ Sent before the plan deadline

Appendix · WSTG v4.2 quick reference

The IDs you will actually reach for on a modern web app. Use this to fill the endpoint table fast — a plan with no IDs cannot demonstrate coverage. It is a starting point, not the whole guide: if your target has a surface that is not listed here, go and find the right ID.

ID	Test	Reach for it on
WSTG-CONF-05	Enumerate admin interfaces	admin panels, /admin, staff routes
WSTG-CONF-06	HTTP methods	any endpoint accepting more than it should
WSTG-IDNT-04	Account enumeration	login, signup, password reset
WSTG-ATHN-03	Weak lockout mechanism	login, OTP, 2FA
WSTG-ATHN-04	Bypassing authentication schema	forced browsing past login, token forgery
WSTG-ATHN-09	Weak password change / reset	reset flows, change-password
WSTG-ATHZ-01	Directory traversal / file include	file download, template, path params
WSTG-ATHZ-02	Bypassing authorization schema	force-browsing a privileged route
WSTG-ATHZ-03	Privilege escalation	role fields, mass assignment on a write
WSTG-ATHZ-04	Insecure direct object references	any `id=`, uuid, order or basket ref
WSTG-SESS-02	Cookie attributes	every Set-Cookie
WSTG-SESS-03	Session fixation	login — does the ID rotate?
WSTG-SESS-05	Cross-site request forgery	every state-changing POST
WSTG-SESS-09	Session hijacking	token replay, JWT tamper and re-sign
WSTG-INPV-01	Reflected XSS	search, filters, error echoes
WSTG-INPV-02	Stored XSS	profiles, comments, tickets, notes
WSTG-INPV-05	SQL injection	anything reaching a query
WSTG-INPV-18	Server-side template injection	templated emails, rendered names
WSTG-INPV-19	Server-side request forgery	URL fetchers, webhooks, imports, previews
WSTG-BUSL-01	Business logic data validation	quantity, price, currency fields
WSTG-BUSL-02	Ability to forge requests	skipped steps, replayed one-time actions
WSTG-BUSL-09	Upload of malicious files	every upload
WSTG-CLNT-01	DOM-based XSS	hash/postMessage into innerHTML sinks
WSTG-CLNT-04	Client-side URL redirect	`?next=`, `?redirect=`
WSTG-CLNT-09	Clickjacking	any sensitive action without frame defence

JWT-specific tests appear as WSTG-SESS-10 in the v4.2 checklist; where your examiner expects the stable-guide numbering, cite WSTG-SESS-09 with WSTG-ATHN-04 and describe the attack.

The XSS Rat · CMWAP · Authorized testing only. Test only what your endpoint table marks IN.

CMWAP example plans & reports

Plans

Reports