Cross-Site Scripting (XSS).

What Is Cross-Site Scripting?

Cross-site scripting, often shortened to XSS, is a weakness in a web application. OWASP, a nonprofit group focused on application security, describes XSS as a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. A script is a small piece of code that a web browser runs.

MITRE lists it as CWE-79, the weakness called improper neutralization of input during web page generation. MITRE says the product fails to neutralize, or incorrectly neutralizes, user-controllable input before it is placed in output that is used as a web page served to other users.

How Does Cross-Site Scripting Work?

OWASP explains that the browser has no way to know that the injected script should not be trusted. The browser sees the script as part of the page, so it runs it. MITRE says there are many variants of XSS, but they all show the same basic weakness: improper neutralization of dangerous input between the attacker and a victim.

OWASP gives an example: an error page shows the text a user typed in the web address, without filtering it. If that text is a script, the victim’s browser runs it. A framework example is in our Apache Juneau 9.2.1 comparison of eight CVEs.

What Are the Main Types of XSS?

• Reflected XSS. OWASP says the malicious payload travels to a vulnerable website, which reflects it back to the user’s browser. It is often delivered through deceptive links.
• Stored XSS. The malicious script is saved on the server, for example in a database, a forum or a comment field. It runs when victims load the stored data.
• DOM-based XSS. This is a client-side flaw, where JavaScript processes untrusted input without proper validation.

Follow One Stored XSS Attack From Input to Stolen Cookie

Stored XSS shows the whole path best. A reflected attack works in a single request and response, so it has fewer stages. The steps follow OWASP’s description of stored attacks.

What Can a Script in the Victim’s Browser Do?

MITRE says an attacker can craft a client-side script that performs activity on behalf of the victim, for example to steal authentication cookies and sensitive data.

OWASP says attackers can steal session cookies, redirect users, modify page content or compromise accounts.

How Can Cross-Site Scripting Be Reduced?

The OWASP prevention cheat sheet and MITRE point to the same main ideas:

• Output encoding. The cheat sheet says variables in a web application need to be protected, and that the right encoding depends on where the data is placed in the page. It warns that using the wrong encoding method may introduce weaknesses.
• Safe ways to write to a page. The cheat sheet recommends safe sinks such as textContent, which treat input as text and not as code, instead of innerHTML.
• Sanitization, when users may submit HTML. OWASP recommends a library called DOMPurify and says later changes to the cleaned output can void the security effort.
• Vetted frameworks. MITRE recommends a vetted library or framework that does not allow this weakness to occur.
• HttpOnly cookies. MITRE suggests setting session cookies to HttpOnly to stop scripts reading them.
• Content Security Policy. The cheat sheet treats it as defense in depth, not the primary mechanism.

Is Cross-Site Scripting the Same as SQL Injection?

No. Both are injection problems, but they hit different targets. OWASP describes XSS as injecting scripts into trusted websites, so the code runs in a visitor’s browser. SQL injection sends database commands to the application.

Is XSS the Same as Remote Code Execution?

Not exactly. MITRE lists executing malicious code among the possible effects of XSS. Remote code execution is the broader idea of running code on a system you do not control.

Related Pages in the Knowledge Hub

• Phishing 101
• Drive-by Compromise
• Valid Accounts