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.