hunt-xss

Validates XSS vulnerabilities by executing canary payloads in isolated browser contexts.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-xss-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-xss
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-xss
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-xss-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security testers often get false positives from scanners that flag reflected input without proving actual script execution. This Skill provides an evidence-gated workflow to confirm whether an untrusted canary truly executes in server, DOM, template, attribute, or URL contexts, separating real XSS from scanner noise. ## Core Features & Use Cases - Evidence-Gated Validation: Confirms XSS only when a self-owned, non-exfiltrating canary actually executes in an isolated browser, verified via DevTools console, network, and CSP reports. - Context-Aware Probing: Covers reflected, stored, DOM, HTML, JavaScript, attribute, and URL contexts with a baseline → single-variable probe → post-baseline → oracle → evidence loop. - Strict Safety Boundaries: Stops immediately on cookie/token reading, phishing, third-party impact, cross-tenant storage, or external callbacks; routes DOM issues to hunt-dom and session/CSRF impact to chain-review. - Use Case: During an authorized web assessment, a scanner reports a reflected parameter. Use this Skill to determine whether the reflection actually executes in the browser or is neutralized by encoding or CSP, producing reproducible evidence. ## Quick Start Use the hunt-xss skill to validate whether the reflected search parameter on my authorized test target actually executes a canary in the browser.

Frequently Asked Questions about hunt-xss

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

FAQPage Schema
How do I confirm an XSS vulnerability is real and not a scanner false positive?

Confirm XSS by proving a self-owned canary actually executes in the browser within the expected context. HTML reflection, encoded output, CSP-blocked payloads, or DOM text display alone do not count as valid XSS evidence.

What XSS contexts does this validation workflow cover?

The workflow covers reflected input, stored input, DOM sinks, HTML context, JavaScript context, attribute context, and URL-based injection. Each context requires determining the input lifecycle, rendering position, encoding, and sanitization before probing.

Can I use this XSS testing skill without authorization?

No. The engagement gate requires declared authorization, locked scope, and an established host, identity, and path baseline before any probing. Only self-owned accounts, test data, and approved rates are permitted.

Why does my XSS payload show in the page but not execute?

Payloads fail to execute when output is properly encoded, blocked by Content Security Policy, rendered as inert DOM text, or intercepted by a WAF. These results are classified as inconclusive, not confirmed vulnerabilities.

What are the limits of this XSS validation approach?

Testing stops immediately at cookie or token reading, phishing attempts, admin or third-party impact, cross-tenant storage, and external callbacks. Stored XSS scenarios must never expose other users or bots to the payload.