| name | pentest-xss |
| description | XSS assessment skill for reflected XSS, stored XSS, DOM XSS, blind XSS, CSP bypass, WAF bypass, source-to-sink analysis, browser context validation, safe payload design, and evidence collection. |
Cross-Site Scripting Assessment
Purpose
Find and validate XSS by mapping controllable sources to browser execution contexts, proving execution safely, and handing off callback or parser work when needed.
Use When
- The owner phase is reflected, stored, DOM, or blind XSS.
- The task needs HTML, attribute, JavaScript, URL, CSS, template, or browser-sink context analysis.
- CSP, WAF, sanitizer, encoding, or client-side source-to-sink behavior is central.
Inputs
- Target URL, parameter, header, cookie, body field, DOM source, or captured request.
- Scope and target allowlist.
- Authenticated session or test account when stored or admin-viewed surfaces are involved.
- Optional CSP, sanitizer behavior, client-side source, proxy traffic, and OOB listener details.
Workflow
- Confirm scope, identity context, and safe test target before injecting payloads.
- Enumerate controllable sources: URL parameters, path segments, headers, cookies, JSON/XML/form fields, uploads, and DOM sources such as
location, postMessage, storage, or referrer.
- Identify reflection or sink context: HTML text, tag, attribute, script block, URL, CSS, template, markdown, rich text, or dangerous DOM sink such as
innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, or framework escape hatches.
- Start with inert markers and context breakers before executable payloads.
- Use minimal payloads that prove execution without stealing tokens, redirecting users, or disrupting production state.
- For stored or blind paths, use unique tokens, timestamps, and a controlled callback endpoint.
- Compare controls: benign marker, escaped marker, alternate context, alternate role/viewer, and expected deny path.
- Stop once capability is proven and preserve exact request, response, rendered context, browser evidence, and timestamps.
Verification Gate
- Do not report XSS from reflection alone; prove browser execution or a clear source-to-sink path with executable context.
- For blind XSS, require deterministic OOB correlation by token, path or subdomain, timestamp, and control outcome.
- For DOM XSS, identify the controllable source, transformation path, sink, and required user/browser action.
- For CSP or WAF bypass claims, show the relevant policy/filter behavior and a working control comparison.
Situational Awareness
- Low-volume manual testing comes before broad match-and-replace automation.
- Use automation only against allowlisted hosts and parameters, with unique traceable markers and stop conditions.
- Pivot to parser/encoding work only when the payload behavior changes across content type, browser, sanitizer, or request parser.
Handoff Criteria
- Hand off to
pentest-outbound-interaction-oob-detection for blind XSS callback setup, tokening, monitoring, and correlation.
- Hand off to
pentest-input-protocol-manipulation for parser differentials, encoding confusion, content-type changes, or request mutation.
- Hand off to
pentest-evidence-structuring-report-synthesis once execution and impact evidence are complete.
Output
- XSS type and context.
- Source, transformation path, sink, and required preconditions.
- Minimal proof payload or marker, redacted if needed.
- Browser or callback evidence with controls.
- Impact statement tied to reachable user role and data/action exposure.
- Remediation guidance for output encoding, sanitizer configuration, CSP, framework escape hatches, or sink replacement.