| name | dom-invader-assistant |
| description | Use this skill whenever the user needs help with DOM Invader in Burp Suite for detecting DOM XSS, prototype pollution, DOM clobbering, or other client-side vulnerabilities. Trigger when users mention Burp Suite's DOM Invader, want to test for DOM-based vulnerabilities, need help with canary injection, postMessage testing, or client-side security testing. Make sure to use this skill for any Burp Suite DOM security testing questions. |
DOM Invader Assistant
A skill for helping users leverage Burp Suite's DOM Invader tool to detect and exploit client-side vulnerabilities.
When to Use This Skill
Use this skill when:
- The user wants to test for DOM XSS vulnerabilities
- The user needs help enabling or configuring DOM Invader in Burp Suite
- The user is investigating prototype pollution or DOM clobbering issues
- The user needs guidance on canary injection techniques
- The user wants to test postMessage handlers
- The user is doing client-side security testing with Burp Suite
Quick Start
-
Enable DOM Invader: Open Burp's embedded browser (Proxy → Intercept → Open Browser), click the Burp Suite logo (top-right), toggle "Enable DOM Invader" ON, and reload the page.
-
Open DevTools: Press F12 or right-click → Inspect to access the DOM Invader panel.
-
Inject a Canary: Copy the canary value and inject it into parameters, forms, or web messages.
-
Monitor Sinks: Watch the DOM Invader panel for flagged sinks and their context.
Core Features
Canary Injection
The canary is a random marker string (e.g., xh9XKYlV) that DOM Invader tracks throughout the application.
Manual injection:
- Copy the canary and inject it into parameters, forms, WebSocket frames, or web messages
- Use "Inject URL params" or "Inject forms" buttons to automatically append the canary to every query parameter or form field
- Search for an empty canary to reveal all sinks regardless of exploitability (great for reconnaissance)
Custom canary (Burp 2024.12+):
- Access Canary settings via Burp logo → DOM Invader → Canary
- Randomize or set a custom string (helpful for multi-tab testing or when the default value appears naturally on the page)
- Copy the value to clipboard
- Changes require browser reload
Web Messages (postMessage)
The Messages sub-tab records every window.postMessage() call, showing origin, source, and data usage.
Modify & resend:
- Double-click a message, edit
data, and press Send (Burp Repeater-like)
Auto-fuzz:
- Enable Postmessage interception → Auto-mutate in settings to let DOM Invader generate canary-based payloads and replay them to the handler
Field meanings:
- origin – whether the handler validates
event.origin
- data – payload location. If unused, the sink is irrelevant
- source – iframe/window reference validation; often weaker than strict-origin checking
Prototype Pollution
Enable under Settings → Attack types → Prototype pollution.
Workflow:
- Browse – DOM Invader flags pollution sources (
__proto__, constructor, prototype) found in URL/query/hash or JSON web-messages
- Test – click Test to open a PoC tab where
Object.prototype.testproperty should exist:
let obj = {};
console.log(obj.testproperty);
- Scan for gadgets – DOM Invader bruteforces property names and tracks whether any end up in dangerous sinks (e.g.,
innerHTML)
- Exploit – when a gadget-sink chain is found, an Exploit button appears that chains source + gadget + sink to trigger alert
Advanced settings (cog icon):
- Remove CSP / X-Frame-Options to keep iframes workable during gadget scanning
- Scan techniques in separate frames to avoid
__proto__ vs constructor interference
- Disable techniques individually for fragile apps
DOM Clobbering
Toggle Attack types → DOM clobbering. DOM Invader monitors dynamically created elements whose id/name attributes collide with global variables or form objects (e.g., <input name="location"> → clobbers window.location). An entry is produced whenever user-controlled markup leads to variable replacement.
Settings Overview
Main
- Enable DOM Invader – global switch
- Postmessage interception – turn on/off message logging; sub-toggles for auto-mutation
- Custom Sources/Sinks – cog icon → enable/disable specific sinks (e.g.,
eval, setAttribute) that may break the app
Attack Types
- Prototype pollution (with per-technique settings)
- DOM clobbering
Misc
- Redirect prevention – block client-side redirects so the sink list isn't lost
- Breakpoint before redirect – pause JS just before redirect for call-stack inspection
- Inject canary into all sources – auto-inject canary everywhere; configurable source/parameter allow-list
Canary
- View / randomize / set custom canary; copy to clipboard. Changes require browser reload.
Best Practices
- Use distinct canary – avoid common strings like
test, otherwise false-positives occur
- Disable heavy sinks (
eval, innerHTML) temporarily if they break page functionality during navigation
- Combine with Burp Repeater & Proxy – replicate the browser request/response that produced a vulnerable state and craft final exploit URLs
- Remember frame scope – sources/sinks are displayed per browsing context; vulnerabilities inside iframes might need manual focus
- Export evidence – right-click the DOM Invader panel → Save screenshot to include in reports
Troubleshooting
DOM Invader panel not appearing:
- Verify it's enabled in the Burp logo menu
- Reload the page after enabling
- Check that DevTools is open
Canary not showing up in sinks:
- Try an empty canary search
- Check if the page is blocking the injection
- Verify the canary is actually being injected
Prototype pollution tests failing:
- Check if the app is using strict mode
- Try different pollution techniques
- Verify the gadget chain exists
DOM clobbering not detected:
- Check for dynamically created elements
- Verify
id/name attributes are being set
- Ensure the clobbering is actually affecting global variables
References
