Skip to content
NEW: auto-exploit Apache Arbitrary File Read & gain RCE with SNIPER

XSS Exploiter

Create credible Proof-of-Concepts and demonstrate the risk of XSS vulnerabilities in web applications

Sample Report | Use Cases | Technical Details

Need to see the full results?

Unlock the full power and feature of our XSS Exploiter! Compare pricing plans and discover more tools and features.

Sample Report

Here is a XSS Exploiter sample report:

  • The payload script can collect the following data during a successful attack:
    • Cookies
    • User URL
    • HTML content of the page
    • Page screenshot
    • Keystrokes
    • User Agent

Download Sample Report

Sample report

XSS Exploiter - Use Cases

The XSS Exploiter allows you to easily demonstrate the true risk of an XSS vulnerability that you found in a web application by creating a Proof-of-Concept scenario. The tool generates a custom JavaScript file that must be included as a payload in the XSS attack. The victim's browser will execute it, sending user data back to this tool. This way, you can harvest the user's cookies, the page HTML content, the page screenshot, the keys pressed by the user.

Web Penetration Testing

Demonstrate to your client how easy it is to exploit the XSS vulnerability that you have found in his web application. Quickly create a Proof-of-Concept simulating a real-life attack.

Social Engineering

Distribute the payload to the target audience and gather data from multiple users. Measure the security awareness of the organization and find privileged accounts (ex. administrators) to extract data from.

Understand XSS Vulnerability

This tool can also be used during web security training to better understand XSS and its risk in real life attacks.

Technical Details


The XSS Exploiter helps exploit Cross-Site Scripting, one of the most critical vulnerabilities in web applications, according to the OWASP Top 10 project.

The tool provides all the elements necessary to exploit an identified vulnerability:
  • The JavaScript payload that fetches data from the user's browser
  • The server-side component that receives the user data
  • A valid SSL certificate on the receiving server that makes the browser trust the script
  • A simple interface to generate the payloads and display the results

You just need to embed the JavaScript payload into an attack vector, send it to the victim, and wait for the data. Here is a sample attack vector:<script src=''></script>


Parameter Description
Label The label which is used to identify your handler. Choose something meaningful for you, such as the name of the web application, the organization, a testing scenario, etc.
Get cookies Have the script fetch the user's cookies. A common field that is stored here is the session cookie. Stealing this can be used to impersonate the user and do actions on their behalf. To do this, you only need to replace your own session cookie when accessing the application with the one stolen from the user.
Get HTML Content Have the script fetch the HTML content of the page the user is on. This includes any modifications caused by user interaction, such as automatic completion of forms or sensitive user data displayed inside an Account Details page.
Get page screenshot Have the script fetch a screenshot of the generated page. This is useful when presenting the Proof-of-Concept to non-technical users, as definite visual proof that the private session of another user can be accessed.
Get keystrokes Have the script intercept and record user keyboard input. A keylogger is especially useful on pages where sensitive user input is requested, such as login pages. It can retrieve usernames, passwords, specific search terms used, or other sensitive user-inputted data, that is not available at the end of the page load.

How it works

Based on the selected options, the tool generates a JavaScript file that can be publicly accessed at a unique URL. That URL can be embedded in an XSS payload which, when accessed by a browser, leads to the script being loaded and executed, fetching the chosen data and sending it back to the server.
The tool is capable of fetching the following information:
  • Source IP address
  • URL Parameters
  • User Agent
  • All HTTP headers
  • Operating system (deducted from User Agent)
  • Request date

Each XSS Handler is unique. Only you can see the data extracted by your handlers. Nobody else can use your payloads or send data back to your handler unless they know your exact URL.
A handler is active for 60 days. After this time expires, you will still be able to view your results, but the handler will stop logging new requests. Additionally, there is a limit of 500 requests that can be logged per handler.