Glossary of Terms

A web application vulnerability that allows attackers to inject malicious scripts into pages viewed by other users. XSS exploits the trust a browser places in websites it visits — when script appears to originate from a trusted domain, the browser executes it without suspicion. The attack targets the user (client-side), not the server. XSS is abbreviated XSS rather than CSS to avoid confusion with Cascading Style Sheets.

A type of XSS attack in which the malicious script is embedded in a URL or request parameter and reflected back in the server's response without being stored. The attacker crafts a malicious link and sends it to a specific victim. When the victim clicks the link, the vulnerable server includes the script in its response, and the victim's browser executes it. The script is never stored on the server — it exists only in the URL sent to the victim and the one-time response it generates. Reflected XSS targets individual victims via crafted links, typically delivered by email.

A type of XSS attack in which the malicious script is permanently saved on the server — in a database, forum post, comment field, or profile. Every user who loads the infected page has the script execute automatically in their browser. No crafted link is required; the script is served as part of the page's normal content. Stored XSS has no specific individual target — all viewers of the infected page are victims. On social networks, stored XSS can self-propagate across the user graph, affecting thousands of accounts from a single post.

The most common language used in XSS attacks. JavaScript runs in every major browser and is enabled by default on most websites and user machines. Running in the browser context, JavaScript has access to session cookies, authentication tokens, page content, form data, and the ability to make network requests. An attacker's XSS payload written in JavaScript can silently read sensitive browser data and transmit it to a remote server without any visible indication to the user.

A small piece of data stored by the browser that identifies an authenticated user session. When a user logs in, the server issues a session cookie. The browser sends this cookie with every subsequent request to prove the user is authenticated. XSS attacks frequently target session cookies — by reading document.cookie via JavaScript, an attacker's script can capture the session token and send it to a remote server. With the stolen token, the attacker can impersonate the victim without knowing their password.

The primary developer defense against XSS. Before displaying user-supplied content in a web page, the application converts characters that have special meaning in HTML — such as angle brackets (< >), quotation marks, and ampersands — into their HTML entity equivalents. This ensures the browser renders the content as visible text rather than interpreting it as HTML tags or executable script. For example, <script> becomes &lt;script&gt;, which displays as literal text and is never executed.

The process of checking user input to ensure it conforms to expected format and content before processing or storing it. For XSS prevention, input validation means rejecting or sanitizing content that contains HTML tags, script elements, or event handler attributes. Validation prevents malicious scripts from entering the data store in the first place. Combined with output encoding (which handles any content that does get through), input validation provides defense-in-depth against XSS at multiple points in the data lifecycle.

An HTTP response header that instructs the browser which sources of content — scripts, stylesheets, images — are permitted to execute on the page. A well-configured CSP can prevent XSS attacks by blocking the execution of inline scripts and restricting script loading to explicitly trusted domains. Even if an attacker successfully injects a script tag, the browser will refuse to execute it if it violates the site's CSP. CSP is a defense-in-depth control that complements input validation and output encoding but does not replace them.

In the context of XSS risk, an authentication token that does not expire represents a compounding vulnerability. Tokens should expire after a defined period to limit the damage window if stolen. A never-expiring token stolen via XSS gives the attacker permanent access to the victim's account — they do not need to re-attack as long as the token remains valid. The Subaru 2017 example demonstrated how a never-expiring token, when combined with an XSS vulnerability, created a permanent, irrevocable breach of vehicle management access.

A particularly dangerous form of stored XSS in which the malicious script is designed to replicate itself — automatically posting or sharing the infected content to every account whose browser executes it. First seen on social networks where user-generated content can be reposted or shared, XSS worms can spread to thousands of accounts within hours of a single initial post. Each newly infected account becomes a vector that exposes its followers or contacts to the same payload, creating exponential propagation.

A variant of XSS where the vulnerability exists entirely in client-side JavaScript code rather than in the server's response. The page's own JavaScript reads attacker-controlled data from the URL hash, query parameters, or other browser-controlled sources, and writes it into the DOM without sanitization. The server's response is never modified — the injection occurs entirely within the browser. DOM-based XSS is harder to detect with server-side scanning tools because the malicious payload never touches the server.