| The "plain" HTML spec is notoriously hard to analyze statically though, due to "error tolerance". The "error tolerance" introduces algorithmic complexity into what could be a parsing problem. Root cause: DOM parsing can lead to a different result when you take the first-pass output, serialize it to HTML again, and use it as input for the second parsing pass. And if it sounds stupid: browser do this, AFAIK. Side note, not security-related: CSS has introduced two-pass rendering since Flexbox, AFAIK. Not the same thing regarding what "rendering" means (there, it's about boxes on screen, not about transforming HTML->HTML, but...). Lehacy inline attributes that allow JS execution are a favorite example, but disabling them via CSP is not a silver bullet. Even if you disallow all attributes like "onclick", "onload", etc, modern document parsing is not context-free, and allows for arbitrarily complex exploits, AFAIK (a href, src or style payload can be just as bad as arbitrary JS execution). The author of the ancient library DOMPurify made a decent amount of money from explaining this thoroughly and providing solutions. In short, detecting XSS is a variant of the Halting Problem in some especially hard cases, as far as I remember. Because HTML parsing is not context-feee. |