|
Trusted Types aim to prevent the injection, XSS-y CSP directives (script-src etc) act as an XSS exploit mitigation that fires after the injection is already there. So, for example, even if the JS execution is stopped, the attacker may still exfiltrate the data via form tags etc. CSP was traditionally deployed by security folks only and is a bit disconnected from the regular dev workflow. For example, if your application does not conform to CSP (i.e. you have an XSS), you can know that only when you deploy it, and the violations keep coming. TT are part of your JS program, and are much closer to how developers prevent other bugs in their programs. For example, since the API uses types, you can even set up your build for the application not to compile if innerHTML is used with a string. Additionally, TT allow the application to be a bit more precise - e.g. maybe you can't refactor the application not to use eval() ever (this is surprisingly common), but would rather make sure that this one eval() instance is secure, and disallow all others. TT solve that elegantly. Your reviewed eval starts using eval(TrustedScript), and all other evals - should they exist - are blocked. In our experience rolling out CSP, its nonced version (w/ no script-dynamic, no unsafe-*) works well for server-side injections, whereas TT cover the client-side better. https://github.com/WICG/trusted-types/wiki/FAQ#do-i-need-tru... |