exploiting-xss-vulnerabilities

Confirms XSS exploitability by injecting marker payloads and verifying browser execution via Playwright.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/bs-koo/gx-security --skill exploiting-xss-vulnerabilities-bs-koo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: exploiting-xss-vulnerabilities
Source: https://github.com/bs-koo/gx-security/tree/main/skills/exploiting-xss-vulnerabilities
Command: npx skills add https://github.com/bs-koo/gx-security --skill exploiting-xss-vulnerabilities-bs-koo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Static scanners flag XSS candidates but cannot prove they are actually exploitable, leaving teams buried in false positives. This Skill dynamically confirms reflected, stored, and DOM XSS vulnerabilities by injecting unique marker payloads into candidate parameters and verifying real script execution in a browser. ## Core Features & Use Cases - HTTP Reflection Testing: The attack_xss.py script injects seven context-specific payloads (HTML body, attribute breakout, JS inline escape) and classifies where markers reflect unescaped in the response. - Browser Execution Confirmation: Playwright MCP workflows navigate pages, submit payloads, and read window.__xss_fired to definitively confirm script execution, with screenshot and console-log evidence capture. - Fail-Closed Safety Gate: scope_guard.py blocks production and public targets at the code level, allowing only authorized local/staging environments. - Use Case: After a static scan flags an unescaped ${param.q} in a JSP search page, run this Skill against the local staging server to inject a marker payload, confirm execution in a browser, and produce a four-element report (vulnerable point, cause, exploit path, fix) with evidence. ## Quick Start Run the XSS exploitation skill against http://localhost:8080/search with parameter q to confirm whether the reflected XSS candidate is actually exploitable.

Frequently Asked Questions about exploiting-xss-vulnerabilities

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I confirm a reflected XSS vulnerability is actually exploitable?▼

Inject a unique marker payload into the candidate parameter with attack_xss.py, then open the page in a browser via Playwright MCP and check whether window.__xss_fired is set. HTTP reflection alone is only a candidate; browser execution confirms the vulnerability.

How to test stored XSS in a web application?▼

Submit the payload through the input form (e.g., a board post body), then navigate to the view page with Playwright and evaluate window.__xss_fired. Stored XSS requires this two-step inject-then-view flow because the script executes when other users load the page.

Can HTTP response scanning detect DOM XSS?▼

No. DOM XSS occurs when client-side JavaScript inserts URL fragments into the DOM, so the payload never appears in the server response. You must load the crafted URL directly in a browser with Playwright and check for marker execution.

Why does the XSS scanner block my target URL?▼

The scope_guard safety gate blocks production-like hosts (www.*, prod*), public IPs, and private ranges by default. Only localhost, 127.x, and reserved TLDs pass automatically; staging domains require explicit allowlist registration via environment variables.

What does a needs-confirmation verdict mean in XSS testing?▼

It means the marker reflected unescaped in the HTTP response, making it a vulnerability candidate, but browser execution has not been verified. A human must run the provided PoC and report whether the script fired before the finding is confirmed or dismissed.