hunt-dom

Validates DOM, postMessage, and Service Worker source-to-sink flows in authorized browser testing.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Client-side vulnerabilities like DOM XSS, insecure postMessage handlers, and Service Worker abuse are hard to confirm because static reflection or console errors do not prove exploitability. This Skill provides an evidence-gated workflow to verify browser-side source-to-sink data flows, origin checks, and storage/navigation trust boundaries without false positives. ## Core Features & Use Cases - Trigger-Based Scoping: Activates on signals such as dom_sink, postmessage_listener, service_worker, client_side_router, local_storage_token, and unsafe_url_sink. - Evidence-Gated Validation: Requires a baseline, single-variable probe, post-baseline comparison, and a browser oracle showing a complete source-to-sink trace before confirming a finding. - Safe Canary Testing: Uses harmless canaries in an isolated browser on your own origin, never reading real localStorage tokens or third-party data. - Use Case: During an authorized web assessment, you find a postMessage listener in a JavaScript bundle. Use this Skill to verify whether messages from an untrusted origin actually reach a dangerous DOM sink, with DevTools traces as evidence. ## Quick Start Use the hunt-dom skill to plan an evidence-gated validation of the postMessage listener and DOM sinks on my authorized test origin.

Frequently Asked Questions about hunt-dom

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

FAQPage Schema
How do I verify a DOM XSS vulnerability without false positives?

Confirm DOM XSS by tracing a complete source-to-sink flow in DevTools where the browser actually executes an untrusted canary input. Static grep results, console errors, and HTML text reflection alone do not count as valid evidence.

How to test postMessage origin validation in a web application?

Send harmless canary messages from your own controlled origin in an isolated browser and check whether the listener validates event.origin before processing data. A finding is valid only if the message reaches a security-relevant sink without proper origin checks.

What signals indicate a client-side trust boundary issue?

Key trigger signals include dom_sink, postmessage_listener, service_worker, client_side_router, local_storage_token, and unsafe_url_sink. These indicate locations where untrusted browser-side data may cross a security boundary.

When should DOM testing stop during a security assessment?

Stop immediately if testing touches other users, real tokens, exfiltration paths, persistent workers, or genuine cross-origin data. WAF blocks, captchas, timeouts, and scanner hits are treated as inconclusive rather than vulnerabilities.

Does string reflection in HTML prove a DOM vulnerability?

No, pure string reflection does not prove a DOM vulnerability. Validation requires the browser to actually execute or process the untrusted canary, with a DevTools trace showing the full source-to-sink path.