XSS-B2 is an XSS testing automation tool for authorized security assessments.
Important: XSS-B2 is intended strictly for systems you own or have explicit written authorization to test (for example, an in-scope bug bounty target or a signed engagement). Testing applications without permission is illegal in most jurisdictions. See our Terms & Disclaimer.
What Is Cross-Site Scripting (XSS)?
Before automating anything, it helps to understand what the tool is looking for. Cross-Site Scripting is a vulnerability that lets an attacker inject malicious JavaScript into a web page that other users then load. Because the script runs in the victim's browser with the site's trust, it can steal session cookies, capture keystrokes, perform actions as the user, or deface the page. XSS has appeared in the OWASP Top 10 for years and remains one of the most common web flaws.
There are three broad types:
- Reflected XSS: the payload is echoed back immediately in the response (e.g., in a search result) and typically delivered via a crafted link.
- Stored XSS: the payload is saved by the application (e.g., in a comment) and served to every visitor — the most dangerous type.
- DOM-based XSS: the vulnerability lives in client-side JavaScript that handles input unsafely, without the server necessarily being involved.
The core defenses are context-aware output encoding, input validation, and a strong Content Security Policy — the same “treat all input as hostile” principle we cover in Secure by Design.
How XSS-B2 Helps
Manually testing every parameter for XSS across a large application is slow and error-prone. XSS-B2 automates the repetitive parts — injecting payloads and, crucially, confirming whether they actually execute in a real browser rather than just appearing in the response. That focus on real JavaScript execution is what reduces the false positives that plague simpler scanners. It pairs naturally with Arjun, which first discovers the hidden parameters worth testing.
Overview
XSS-B2 is an enhanced XSS automation tool designed to help security professionals identify Cross-Site Scripting (XSS) vulnerabilities during authorized penetration tests and bug bounty engagements. With a focus on real JavaScript execution detection, XSS-B2 offers advanced features such as:
- Proxy Support: Route requests through configured proxies to test how an application responds across different network paths and to stay within the network scope defined by an authorized engagement
- User Agent Rotation: Vary the User-Agent header to verify how the server responds to different client types
- Automated CAPTCHA handling (lab use only): In controlled lab environments where you own the CAPTCHA keys, XSS-B2 can solve audio challenges so automated tests can reach the form under test. This is intended purely for testing your own applications — never for circumventing protections on systems you do not own
- Terminal Progress Bar: Visualize scan progress with a rich terminal interface
- JSON Reporting: Generate detailed reports for comprehensive vulnerability analysis
Features
- Real XSS Detection: Focus on actual JavaScript execution, minimizing false positives
- GET and POST Method Support: Test both HTTP methods for comprehensive vulnerability scanning
- Arjun Integration: Leverage Arjun for parameter discovery to enhance scan effectiveness
- Custom Payloads: Load your own XSS payloads for tailored testing
- Verbose Output: Enable detailed logging for debugging and analysis
Installation
- Clone the repository:
git clone https://github.com/username/XSS-B2.git - Install dependencies:
pip install -r requirements.txt - Run the tool:
python3 XSS-B2.py -h
For Kali Linux systems, you should also install these system packages: apt update && sudo apt install -y chromium chromium-driver ffmpeg
Usage
python3 XSS-B2.py -u <target_url> -o <output_dir> [-p <proxy_file>] [-m <method>] [--bypassrecaptcha]
Command-Line Arguments
-u, --url <URL>: Single target URL-l, --list <FILE>: File with list of URLs-o, --output-dir <DIR>: Output directory for results-p, --proxy <FILE>: File containing proxy list (HTTP, HTTPS, SOCKS5) to test behavior across network paths and honor engagement scope--proxy-only: Force proxy-only mode (no direct connection fallback)--test-proxies: Test all proxies and exit--show-browser: Show browser (run in visible mode)--timeout <SEC>: Page load timeout in seconds (default:10)--delay <SEC>: Delay between requests in seconds (default:1)--threads <NUM>: Number of threads for Arjun (default:5)--payloads <FILE>: Custom XSS payloads file (one per line)-m, --method <method>: HTTP method for testing payloads (default: GET)--bypassrecaptcha: Enable automated audio-challenge solving for authorized testing of your own CAPTCHA-protected forms in a lab environment--tbar: Enable terminal progress bar (requires rich)-v, --verbose: Enable verbose/debug output--log-file <FILE>: Save logs to file
Requirements
- Python3.7+
- Selenium
- Requests
- BeautifulSoup4
- Pydub
- SpeechRecognition
- Rich
Disclaimer
Use XSS-B2 only on authorized targets. The authors and contributors are not responsible for any misuse or damage caused.
Contributing
Contributions are welcome! Please submit pull requests or issues on GitHub.
License
XSS-B2 is licensed under the MIT License. See LICENSE for details.
Frequently Asked Questions
Why focus on “real JavaScript execution” instead of just matching the payload in the response?
A payload appearing in the response does not always mean it executes — encoding or context can neutralize it. By driving a real browser and confirming execution, XSS-B2 reports vulnerabilities that are genuinely exploitable, dramatically cutting false positives.
Should I test XSS on production systems?
Only with explicit authorization, and preferably against a staging copy where possible. Stored-XSS payloads in particular can affect real users, so coordinate with the system owner and stay within scope.
Does finding no XSS mean the app is safe?
No. Automated tools reduce effort but cannot guarantee coverage — DOM-based and context-specific XSS often require manual analysis. Treat automation as a force multiplier, not a substitute for skilled testing.
Related Reading
- Arjun: HTTP Parameter Discovery
- Secure by Design: Start With Security, Not After
- Penetration Testing: Finding Vulnerabilities Before Attackers Do