Cross-site scripting (XSS)

The flaw

Cross-site scripting (XSS) is when a site displays data from a user without properly neutralising it, so that script written by an attacker runs in a victim's browser. The browser cannot tell the difference between the site's own script and an injected one, so it runs both. The attacker's script then acts as the victim: it can read their session, change the page, or send their data away.

How a tester shows it (in a lab)

A harmless proof is to enter something like a small snippet that would pop up a message box or simply change text on the page, into a field, and see whether it runs when the page is shown. If it does, the input was not made safe. The point is to prove the flaw, not to attack real users; you record it and move on.

The fix: treat output as text

• Output encoding/escaping: when you put user data into a page, encode it for that context (HTML, attribute, JavaScript, URL) so it is shown as text, not run as code. Modern frameworks (React, Angular, etc.) do this by default.
• Content Security Policy (CSP): an HTTP header that tells the browser which scripts are allowed, so injected inline scripts are blocked even if they slip in.
• Mark session cookies HttpOnly so scripts cannot read them, limiting the damage if XSS occurs.
• Validate and sanitise rich input (like HTML comments) with a trusted library.

Detection and defence summary

Detection: unusual markup in stored data, CSP violation reports, and a WAF flagging script-like input. Defence (primary): context-aware output encoding, plus a strong CSP as a safety net. The key mental model: user input should always arrive on the page as text to be displayed, never as code to be executed.