Cross-site scripting (XSS)

Cross-site scripting happens when data supplied by one person reaches another person’s browser as executable markup rather than as text. A comment field, a display name, a search term echoed back on the results page, a URL parameter written into the DOM — any of these becomes an injection point when the value is interpolated into HTML without being encoded for the place it lands. The browser has no way to distinguish script the developer wrote from script that arrived in a database column, so it runs both with identical authority.

What makes it consequential is the origin. Code executing this way inherits everything the visitor’s session has: cookies not protected from scripting, tokens held in local storage, the ability to issue authenticated requests that look entirely ordinary to the server, and control over what the page displays. An attacker rarely wants the alert box used to demonstrate the bug. They want a session, a password typed into a form they have redrawn, or a quiet request that changes an email address on an account they do not own.

The three shapes it takes

• Stored. The payload is saved server-side and served to everyone who views the affected record, which makes it the most damaging variant because the attacker chooses the content once and the application distributes it.
• Reflected. The payload travels in the request and comes straight back in the response, so exploitation needs a crafted link and a reason for somebody to follow it.
• DOM-based. Nothing dangerous ever crosses the server; client-side code reads a fragment or a parameter and writes it into the page, which means server logs show a perfectly clean request.
• Mutation cases, where sanitised markup is rewritten by the browser’s own parser into something executable, which is why hand-written filters lose to a maintained library.

Encoding is contextual: the escaping that makes a value safe inside an HTML element is not the escaping that makes it safe inside an attribute, a URL or a block of JavaScript.