Cross-site scripting, abbreviated XSS, is an attack in which an adversary gets malicious script into a web page that other users then load, so the script runs in those users’ browsers with the trust the site normally enjoys. OWASP defines it as “a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites” (owasp.org/www-community/attacks/xss/). Because the browser cannot tell the injected script apart from the site’s own code, the attacker’s JavaScript can read cookies, hijack a logged-in session, deface the page, or perform actions as the victim.
The CWE database catalogs this as CWE-79, “Improper Neutralization of Input During Web Page Generation.” The weakness arises when an application places user-controllable input into a page served to other users without neutralizing it first (cwe.mitre.org/data/definitions/79.html). OWASP and CWE both distinguish three main forms: reflected XSS, where the payload bounces back immediately in a response such as a search result; stored XSS, where the payload is saved on the server and served to everyone who later views it; and DOM-based XSS, where client-side script writes attacker input into the page without any server round trip.
The defenses follow from the cause. Output encoding, sometimes called escaping, renders user input as inert text in whatever context it lands, whether HTML body, attribute, or script, so the browser displays it rather than executing it. A Content Security Policy adds a second layer by restricting which scripts the browser is allowed to run at all, limiting the damage of any injection that slips through.
XSS is the web-facing sibling of SQL injection: both are instances of the general code-injection problem, differing only in which interpreter is tricked. SQL injection targets the database engine; XSS targets the JavaScript engine inside the victim’s browser. It has been a fixture of the OWASP Top Ten since the list began.