The "plain" HTML spec is notoriously hard to analyze statically though, due to "error tolerance". The "error tolerance" introduces algorithmic complexity into

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.