Cross-Site Scripting (XSS)

What Cross-Site Scripting Is

Cross-Site Scripting (XSS, CWE-79) is a vulnerability that lets an attacker inject and execute malicious JavaScript in someone else's browser. Unlike SQL injection, which attacks the server, XSS attacks the users of the application. The victim's browser runs the attacker's script as if it were a legitimate part of the site, with all the privileges of that origin.

The root cause is the same family as injection: the application takes untrusted user data and places it into an HTML page without properly handling it. When the browser interprets that page, it cannot distinguish between the developer's legitimate HTML and the injected malicious code. XSS belongs to the injection category of the OWASP Top 10 and remains one of the most common vulnerabilities on the web.

Reflected XSS

Reflected XSS is the simplest variant. It happens when data sent in a request, usually through a URL parameter or a form, is returned immediately in the response without encoding. For example, a search page that displays "No results found for: [term]" and places the term directly into the HTML.

The attacker crafts a specially designed URL containing the script and sends it to the victim by email, messaging, or a link on another site. When the victim clicks, the server reflects the script in the response and the browser executes it. Because the attack lives in a link and is not stored, it requires social engineering for the victim to trigger the URL, but it is still very dangerous because it runs in the context of the trusted site.

Stored and DOM-Based XSS

Stored XSS (persistent) is the most serious. Here the malicious code is saved on the server, for example in a comment, a user profile, or a forum message, and is served to everyone who views that content. A single injection can affect thousands of users with no need for social engineering, since the script is delivered automatically every time the compromised page loads.

DOM-based XSS is different: the vulnerability lives entirely in the client-side JavaScript code. It occurs when a script on the page takes data from an attacker-controllable source (such as the URL) and writes it into the DOM in an unsafe way, for example through innerHTML. In this case the server may never see the malicious payload, which makes it harder to detect with traditional server-side tools.

The Impact of XSS

Once an attacker can execute JavaScript in the victim's browser, the possibilities are broad. They can steal session cookies (if they are not protected with HttpOnly) and hijack the user's session, capture keystrokes to steal credentials, modify the page content to perform convincing phishing, or perform actions on behalf of the victim using their permissions.

In administrative applications, an XSS aimed at an administrator can escalate to a full system compromise. XSS can also be used to spread web worms that replicate from user to user, as happened in historical incidents on social networks. The impact therefore ranges from the theft of individual data to the mass compromise of a platform.

How to Mitigate It

The primary defense is contextual output encoding. Before inserting any untrusted data into a page, it must be encoded according to the context where it is placed: HTML, HTML attribute, JavaScript, URL, or CSS. Encoding converts dangerous characters into their harmless equivalents, so the browser displays them as text instead of executing them. Modern frameworks like React or Angular encode by default, which greatly reduces the risk, but you must be especially careful with APIs like dangerouslySetInnerHTML.

As a second layer, the Content Security Policy (CSP) is an HTTP header that tells the browser which origins it may load and execute scripts from, blocking the execution of injected inline code. A well-configured CSP can neutralize many XSS attacks even when an encoding flaw exists. Complement this with the HttpOnly attribute on session cookies so they are not accessible from JavaScript, validate input on the server side, and use Burp Suite or OWASP ZAP to detect reflected points during testing. The combination of output encoding plus CSP is the standard defense against XSS.