reflected into the results page. It's non-persistent, so exploitation requires tricking a specific victim into clicking a crafted link (phishing), but it's extremely common because search boxes, error messages, and redirects echo input everywhere. DOM-based XSS is the odd one out: the injection happens *entirely in the browser*, with no unsafe server response involved. Client JavaScript reads an attacker-controllable source (location.hash, document.referrer, postMessage data) and writes it to a dangerous sink (element.innerHTML, eval, document.write) without sanitizing. Because the exploit c"}},{"@type":"Question","name":"Why does XSS defense require context-aware output encoding rather than a single escape function?","acceptedAnswer":{"@type":"Answer","text":"Because \"escaping\" means \"neutralize the metacharacters of whatever context the data lands in,\" and HTML documents have *several* contexts, each with different dangerous characters and different escaping rules. One escapeHtml() applied everywhere is safe in some spots and useless in others. The contexts and their tells: as HTML element text, the dangers are < > & and HTML-entity encoding is correct. As an HTML attribute value, you must also encode quotes and always quote the attribute — otherwise value= breaks out with a space and adds an onerror= handler with *no < needed*, so HTML-text escaping alone doesn't save you. In a URL attribute (href/src), entity-encoding does nothing about a javascript: scheme, so you must validate the scheme. Inside a