Encoding for the output context

XSS was merged into A05 because it is injection — the same mechanism as SQL injection with a different interpreter. But one thing makes it harder than SQL injection in practice, and that is this lesson's subject: HTML is not one interpreter, it is five nested interpreters.

The same string, placed in five different spots on a page, needs five different treatments:

The most important point, and where a framework cannot save you: encoding for the wrong context both fails to protect and corrupts the data. HTML-encoding a string then placing it inside <script> yields " sitting in JavaScript code — it does not stop </script> and it renders the string wrongly.

Two contexts deserve their own note, because they are the source of nearly all remaining XSS in modern applications:

(1) href and src. Encoding is not enough, because javascript:alert(1) contains no character that needs encoding. This context needs a scheme check: allow http, https, and perhaps mailto. This is the most common XSS in React — href={userUrl} is not protected by React.

(2) DOM sinks. innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, setTimeout with a string, and dangerouslySetInnerHTML/v-html. There is no correct encoding here — the data enters a fresh HTML parser, so it needs sanitising (DOMPurify) or a different approach.