Cross-Site Scripting is a security vulnerability where attackers inject malicious scripts into web pages viewed by other users. These scripts can steal session tokens, cookies, and other sensitive data, or perform actions on behalf of the user. XSS comes in several forms: reflected (via URL parameters), stored (in databases), and DOM-based (in client-side JavaScript). Prevention requires proper input validation, output encoding, and Content Security Policy implementation.
Cross-site scripting (XSS) is a vulnerability that lets an attacker inject JavaScript into a page that other users then load. If an application takes input, a search term, a comment, a URL parameter, and renders it in the page without proper encoding, an attacker can supply script instead of text. That script runs in the victim's browser with the victim's session, letting it steal cookies, capture keystrokes, or act as the user.
There are three classic forms. Stored XSS saves the payload on the server, in a comment or profile field, so it hits every visitor. Reflected XSS bounces the payload off the server via a crafted link. DOM-based XSS never reaches the server at all: vulnerable client-side JavaScript writes attacker-controlled data into the page. Each needs a slightly different defence, but all end with attacker code running in a trusted context.
The core defences are contextual output encoding, input validation, and a strong Content Security Policy that limits what injected script can do. Because XSS ultimately results in unexpected JavaScript executing in the browser, client-side monitoring adds a useful layer: cside can flag when a page starts running script that reads sensitive fields or exfiltrates data, catching exploitation even when a specific injection flaw was missed in code review.
Anything the user's browser can do in that session: read and exfiltrate cookies or tokens, capture what the user types including passwords and card numbers, rewrite page content to phish, or make authenticated requests as the victim. Severity depends on the privileges of the affected user.
A well-configured CSP makes exploitation much harder by restricting inline scripts and untrusted sources, but it is a mitigation, not a cure. Misconfigurations, allow-listed but abusable domains, and DOM-based sinks can still be exploited. CSP works best combined with proper output encoding.
We answer client-side security questions every day. Bring yours.