What Is Cross-Site Scripting (XSS)?

Cross-site scripting occurs when an application includes untrusted input in a page without neutralising it, so that the input executes as script in another user's browser.

The victim is the user rather than the server, which is why it is sometimes underrated. In practice it yields session theft, credential capture and actions performed as the victim, which is account takeover by another route.

The three forms

Stored — the payload is saved by the application and served to everyone who views the affected content. The most serious, because it requires no interaction from the victim beyond normal use.

Reflected — the payload is in the request and echoed into the response, requiring the victim to follow a crafted link. Document-based — the flaw is in client-side code manipulating the page, and the payload may never reach the server at all, which means server-side logging shows nothing.

What it achieves

Reading session cookies, unless they are marked inaccessible to script. Capturing keystrokes and form input on the affected page, including credentials. Performing actions as the victim, with their full privileges.

Modifying page content to phish convincingly, from the genuine domain with a valid certificate. That last case is why it is a serious finding even where no data is directly read.

The fix is contextual output encoding

Encoding depends on where the data lands. Text within a page, an attribute value, a script block, a style and a URL each require different treatment, and applying the wrong one leaves the flaw open.

Modern frameworks encode by default, which has reduced this substantially. The residual risk sits in the places developers deliberately bypass that default — inserting raw markup, building HTML by hand, or passing content through functions that interpret it.

Defence in depth around it

A content security policy restricts which scripts may execute, which can neutralise injected script even where the flaw exists. It takes effort to deploy on an existing application and is valuable.

Session cookies marked inaccessible to script remove the simplest payoff. Requiring re-authentication for sensitive actions means a stolen session cannot change credentials or payment details.

Finding it

Dynamic testing and manual testing are effective, because the flaw is observable in the response. Static analysis helps with server-side cases and struggles with client-side ones.

The document-based form needs client-side analysis specifically, and is regularly missed by testing that only examines server responses — worth confirming is in scope when commissioning an application test.

Related injection in the browser

Two neighbours are worth knowing. Request forgery causes a victim’s browser to perform an authenticated action they did not intend, and is addressed by anti-forgery tokens and appropriate cookie policy.

Clickjacking overlays or frames your page so a user clicks something other than what they see, and is addressed by frame-ancestor restrictions. Both exploit the browser’s willingness to attach credentials to requests, and both are configuration rather than code changes.

Where to start

Search your front-end code for the places where raw markup is inserted deliberately, bypassing framework encoding. That short list is where this flaw now lives.

See web application firewalls. GuardsArm delivers application penetration testing.