Cross-Site Scripting (XSS) is one of the most well-known web application vulnerabilities. It even has a dedicated chapter in the OWASP Top 10 project and it is a highly chased after vulnerability in bug bounty programs.
The risk of a Cross-Site Scripting vulnerability can range from cookie stealing, temporary website defacement, injecting malicious scripts, or reading sensitive page content of a victim user.
The scanner works in two steps:
- Spider the target: In this first step, the tool tries to identify all the pages in the web application, including injectable parameters in forms, URLs, headers, etc.
- Test for XSS: For each page discovered in the previous step, the scanner will try to detect if the parameters are vulnerable to Cross-Site Scripting and report them on the results page.
The table below shows the differences between the Light scan and the Full scan:
|Scanner capabilities||Light scan||Full scan|
|Spider max URLs||20||500|
|Spider max duration||1 minute||15 minutes|
|Active scan max duration||2 minutes||30 minutes|
|Target URL||This is the URL of the website that will be scanned. All URLs must start with http or https.|
|Light Scan||This scan is faster but less comprehensive than the full scan.|
|Full Scan||This is a complete Cross-Site Scripting assessment of the target web application.|
How it works
The XSS Scanner had been using the OWASP ZAP scanning engine (which is one of the world’s most popular open-source security tools, actively maintained by hundreds of international developers). However, we improved upon it, and we're now using a proprietary internal scanning engine for the XSS Scanner, to your benefit.
') and it will try to see if they are returned in the response page without sanitization. If this is true, the page and parameter are declared vulnerable.
Get more information about Cross-Site Scripting and how to remediate this vulnerability on the dedicated OWASP XSS Page.