What is Cross-Site Scripting (XSS)?

Definition

Cross-site scripting (XSS) is a client-side code injection attack in which an attacker injects malicious scripts into content served by a trusted web application. When other users load the affected page, their browsers execute the injected script in the context of the legitimate site — with access to cookies, session tokens, DOM content, and the ability to make requests on the user's behalf.

XSS is consistently in the OWASP Top 10. Unlike server-side attacks like SQL injection, XSS targets the application's users rather than its backend directly. A successful XSS attack can compromise every session active on a vulnerable page.

Types of XSS

Reflected XSS

The malicious script is embedded in a URL or form parameter. The server reflects the input back in the response without sanitization. The victim is tricked into clicking a crafted link, their browser executes the script, and the attacker harvests the result. The script is not stored — it exists only in that one request-response cycle.

Stored XSS (Persistent XSS)

The malicious script is stored in the application's database — in a comment, profile field, message, or any user-controlled content. Every user who views the affected page executes the script. Stored XSS is more dangerous than reflected XSS because it can compromise many users without requiring individual targeting.

DOM-based XSS

The attack occurs entirely in the browser. A client-side script reads attacker-controlled data (from the URL, localStorage, postMessage) and writes it to the DOM without sanitization. The server may never see the malicious payload. DOM XSS is increasingly common in single-page applications.

Impact

XSS enables attackers to:

• Steal session cookies and hijack authenticated sessions
• Capture keystrokes including passwords and credit card numbers
• Redirect users to phishing pages
• Modify page content to deceive users (defacement, fake forms)
• Make authenticated requests on the victim's behalf (CSRF-like actions)
• Exfiltrate sensitive data visible to the user

Prevention

Output encoding

The primary defense. Every piece of user-controlled data rendered in HTML must be encoded so that HTML special characters cannot be interpreted as markup. Encode for the correct context: HTML entity encoding for HTML content, JavaScript string escaping for JS context, URL encoding for URLs.

Content Security Policy (CSP)

A browser security header that restricts which scripts can execute on a page. A strict CSP that blocks inline scripts and requires nonce-based script loading significantly reduces the exploitability of XSS vulnerabilities.

Avoid dangerous APIs

innerHTML, document.write, eval(), setTimeout/setInterval with string arguments, and similar DOM APIs create XSS risks when called with user-controlled data. Use textContent instead of innerHTML; use createElement instead of document.write; never eval user data.

Input validation

Validate that inputs conform to expected formats. For fields that accept only alphanumeric input, reject everything else. This reduces but does not eliminate XSS risk — validation context determines what is safe, and context is complex.

XSS and Autonomous Code Governance

XSS detection relies on taint analysis: tracing the flow of user-controlled data from input sources to rendering sinks. Hydra maps these data flows statically, identifies where unsanitized user data reaches innerHTML, eval, or template interpolation, and generates fixes that apply the correct encoding or safe API substitution. Because XSS fixes are context-sensitive, Hydra analyzes the rendering context before generating a fix — HTML body, HTML attribute, JavaScript, URL — and applies the appropriate encoding function.