Cross-Site Scripting (XSS)
XSS (Cross-Site Scripting) is a web vulnerability in which attacker-injected script runs in the victim's browser as if it were legitimate code from the site itself. The root cause is usually that user input or external data is inserted into HTML or the DOM unsafely. Once execution begins, it can lead to information disclosure, UI tampering, and requests sent with the victim's privileges.
βΆArchitecture Diagram
π ProcessDashed line animations indicate the flow direction of data or requests
Web applications constantly take user input and show it again on the page. Comments, profile bios, search terms, and preview screens all create moments where a value provided by a user is inserted back into HTML or the DOM. If that insertion is not done safely, an attacker can supply script instead of plain text, and the browser cannot tell whether that script was intended by the developer or planted by the attacker. The problem is that only one missed path is enough. Out of dozens of input flows, a single missing output escape or a single unsafe innerHTML insertion creates an execution path. Once the script runs, it can act with the user's session, read sensitive information, and issue unwanted requests.
If early web vulnerabilities were dominated by server-side input validation failures, the richer the web became, the more opportunities there were for code to be assembled and executed in the browser itself. User-generated content, rich-text editors, third-party tags, and direct DOM manipulation in SPAs kept XSS among the most common web security problems for years. Frameworks reduced risk through automatic escaping and safer templating defaults, but not all code stays inside those safety rails. Escape hatches for raw HTML and direct browser APIs still exist, which is why XSS is not an old, retired vulnerability but a recurring risk even in modern frontend codebases.
XSS proceeds in three broad steps: the attacker injects script, the application places it into a page, and the browser executes it. Stored XSS happens when malicious input is saved in a database or other persistent store and then executed later when another user loads the page. Reflected XSS happens when a request value is immediately mirrored in the response, as with search terms or error messages. DOM-based XSS happens when client-side JavaScript reads URL fragments or external data and inserts it into the DOM unsafely. Once execution starts, the script gains same-origin privilege. That means it stands in nearly the same position as the site's own code. It can read cookies that are not HttpOnly, inspect personal information in the DOM, and send requests using the victim's authenticated context. That is why XSS should be understood not as a harmless alert box trick, but as browser-side privilege capture.
Spotting the raw HTML insertion path
function Comment({ html }: { html: string }) {
return <div dangerouslySetInnerHTML={{ __html: html }} />;
}The value inside `__html` goes straight into the DOM. Reading that line explains why this is the classic XSS execution path.
Rendering user input as text
function Comment({ text }: { text: string }) {
return <p>{text}</p>;
}JSX braces render a string as text by default. The same input behaves differently when it is treated as HTML versus plain text.
XSS and CSRF both abuse the victim's browser, but the mechanisms differ. XSS injects code into a trusted page and makes the browser execute it. That means it can read responses, modify the DOM, and steal tokens. CSRF causes another site to send a request using the victim's existing authentication state, but it usually cannot read the response body. The difference shapes the defenses. CSRF tokens verify that a request is genuine, but if the page already has XSS, the attacker may be able to read that token. CSP is strong at blocking malicious script execution, but if the server never verifies request intent, CSP alone does not finish the CSRF problem. The two attack classes overlap in outcome but not in the point of failure.
In practice, XSS reviews focus on places where user-controlled data comes back as HTML. Comments, markdown previews, admin-side custom templates, and code that reads query strings and assembles the UI are all common danger zones. The defense is never just one thing. Output encoding and HTML sanitization are the baseline. On top of that, risky DOM insertion paths such as innerHTML or raw HTML escape hatches should be minimized, and narrowly controlled when they are truly necessary. Finally, CSP reduces blast radius so that even if script slips into the page, execution does not necessarily succeed. Token storage strategy is also tightly connected to XSS. If highly sensitive authentication material lives in localStorage or IndexedDB, an XSS issue can expose it directly. HttpOnly cookies block direct script reads, but that alone does not end the problem, so DOM insertion paths and request authority still need to be reviewed together.