XSS Payload Tester & Cross-Site Scripting Checker

Understanding Cross-Site Scripting (XSS) Vulnerabilities

Cross-Site Scripting (XSS) is a critical security vulnerability where an attacker injects malicious client-side scripts (usually JavaScript) into otherwise trusted websites. XSS remains a fixture on the OWASP Top 10 web application vulnerabilities because a single unescaped output point can compromise a user's entire session. When a victim's browser executes the injected script, the attacker gains the ability to steal session cookies, hijack active accounts, capture keystrokes, modify page content via DOM manipulation, or redirect the user to phishing portals.

To properly defend applications, security teams must categorize XSS into three primary vectors:

• Reflected XSS: The malicious script is part of the request sent to the server (e.g., a search parameter) and is echoed back in the response immediately.
• Stored XSS: The payload is saved on the server's database (e.g., a forum post, user profile name) and executes when other users fetch and render that content.
• DOM-Based XSS: The vulnerability exists entirely in client-side code, where JavaScript reads input from an untrusted source (like location.hash) and writes it directly to an unsafe sink (like element.innerHTML).

How it Works: The XSS Execution and Sanitization Mechanics

To understand how an XSS attack succeeds, it is helpful to look at how web browsers parse HTML. An HTML document is a structured tree of nodes. If an application prints user input directly into this document without escaping, the browser cannot distinguish between intended structure and user content. If you write <script>alert(1)</script>, the HTML parser reads the < character and immediately switches to script parsing mode, executing the instructions.

Preventing XSS requires context-aware output escaping:

1. HTML Body Context: Convert special characters into safe HTML entities. For example, < becomes <, > becomes >, and & becomes &. The browser displays the character visually but does not parse it as executable markup.
2. Attribute Context: When outputting values inside quoted tag attributes (e.g., <input value="USER_INPUT">), attackers attempt to breakout using double quotes: " onfocus="alert(1). To prevent this, double quotes (") must be encoded as " and single quotes (') as '.
3. JavaScript Context: When inserting server variables into inline <script> tags, standard HTML escaping is ineffective. Attackers can breakout using closing tags (</script>). Values must be serialized safely (e.g., using JSON serialization) and characters like \ must be escaped.

Worked Examples: 5 Common Attack Vectors and Fixes

Example 1: Classic Script Tag Injection

• Payload: <script>alert(document.cookie)</script>
• Mechanics: Directly forces the browser to open a scripting block. If session cookies lack the HttpOnly flag, the script can extract and transmit them to an external server.
• Remediation: HTML-entity encode < to < and > to >.

Example 2: Attribute Breakout & Event Handler

• Payload: "><img src=x onerror=alert(1)>
• Mechanics: The leading " closes the current attribute, and the > closes the current tag. The attacker then injects a new <img> element with a broken source (src=x) which automatically triggers the onerror event handler to run the script.
• Remediation: Encode " to " and sanitize tag attributes.

Example 3: JavaScript URI Sink

• Payload: javascript:alert(document.domain)
• Mechanics: When injected into a hyperlink <a href="USER_INPUT">, clicking the link triggers the browser's JavaScript protocol interpreter instead of navigating to a website.
• Remediation: Enforce a strict protocol allowlist (e.g., only allow http:// or https:// schemes).

Example 4: SVG Script Bypass

• Payload: <svg/onload=alert(1)>
• Mechanics: Bypasses basic filters that search only for <script> tags. The SVG element loads and immediately triggers its inline onload handler.
• Remediation: Use robust parsing libraries like DOMPurify to strip unauthorized attributes.

Example 5: HTML Entity Bypass

• Payload: <script>alert(1)</script>
• Mechanics: Useful if the application decodes HTML entities after filtering but before rendering into the DOM, reconstituting the executable tags.
• Remediation: Never perform double decoding of inputs; sanitize at the final output boundary.

Comparison: XSS Mitigation Strategies

Edge Cases, Sanitization Bypass, and CSP Limitations

Experienced attackers use complex formatting rules to bypass standard filters:

1. Mutation XSS (mXSS): Browsers try to repair broken HTML before rendering it in the DOM. An attacker can write an inert payload that, when parsed and normalized by the browser, transforms into an active XSS exploit. Standard regex filters cannot predict how a browser will mutate HTML.
2. Nested Event Handlers & Polyglots: Attackers construct payloads that function in multiple contexts simultaneously (e.g., working inside an attribute, a script tag, and a plain body at the same time). Stripping single keywords like script can be bypassed by nesting (e.g., <sc<script>ript>).
3. Loose Content Security Policies: If a site allowlists a broad CDN (like cdnjs.cloudflare.com) in its script-src directive, attackers can bypass CSP by loading old, vulnerable library files (such as angular.js) to execute arbitrary code via client-side template injection.