DOMPurify, Security in the DOM, and Why We Really Need Both [pdf]

Trusted Types are the solution for this: https://developers.google.com/web/updates/2019/02/trusted-ty...

With Trusted Types on, unsafe strings are disallowed directly at the unsafe sink level, ie innerHTML doesn't accept strings anymore, but instances of TrustedHTML. TrustedHTML can only be created by a Trusted Types Policy, and by isolating policies from user-generated and other untrusted content you guarantee that you can't have XSS holes.

* Note for the curious: This is how we're locking down lit-html so that it's completely safe from XSS. We have a simple policy that's only accessible to the template strings processor, so that the only strings trusted in an application are the template literals written by developers. All other strings will not be allowed at unsafe sinks. We don't even trust the other internals of lit-html. See https://github.com/Polymer/lit-html/blob/ceed9edc0aecdf82588...

Trusted Types are good for most cases, but the case from the PDF is one where you're given a blob of untrusted HTML that you do still want to render (an HTML formatted email).

Trusted Types will prevent a dependency or careless developer from setting innerHTML without going through a policy you've evaluated and decided to trust, but it doesn't have an HTML sanitizer, so for those cases a library like DOMPurify is still necessary.

I'm skeptical about trusted types. It seems very heavy and needs 100% buy-in to work.

Reminds me how CSP was seen as the glorious savior. But so far it only helps the big sites (Google, Facebook Twitter etc)