Skip to content
Krzysztof Kotowicz edited this page Feb 8, 2019 · 17 revisions

Do we need Trusted Types when we have a CSP?

Most likely - yes.

The main difference between is in that CSP is fundamentally an exploit mitigation: It does not remove the underlying bug from the code (e.g. injection of unsanitized untrusted data into HTML markup), but rather attempts to prevent its exploitation. Depending on the nature of the specific injection, there can still be security issues (see http://lcamtuf.coredump.cx/postxss/; this is probably more relevant wrt server-side injection, but fundamentally the point stands).

Aside from this fundamental issue, there are strong indications that it's fairly difficult to apply CSP correctly in practice, https://research.google.com/pubs/pub45542.

In addition, many web frameworks introduce "script gadgets" which permit a HTML injection vulnerability to turn into XSS even with CSP in place (see https://github.com/google/security-research-pocs/tree/master/script-gadgets).

Types on the other hand are a tool that helps developers build applications that are fundamentally free of underlying root-cause injection bugs to a high degree of confidence.

That said, CSP is nevertheless a valuable complementary mitigation. Given a web framework that helps with setting up and maintaining policies, it's very little effort to deploy, and there's really no reason not to use it in addition to Trusted Types.

See also #116

Do Trusted Types prevent DOM XSS?

In principle - no; it practice - yes.

Trusted Types aim to lock down the insecure-by-default parts of the DOM API, that end up causing a lot of DOM XSS bugs for web applications out there. Additionally it allows to design applications in a way that isolates the security-relevant code into an orders-of-magnitude smalller, reviewable and controllable fragments. While it is possible that those (user-defined) functions are insecure and introduce DOM XSS, the task of preventing, detecing and fixing this becomes managable, even for very large applications. And this is what may in practice prevent DOM XSS.

Why 'Trusted' and not 'Safe'?

Trusted in this context signifies the fact that the application author is confident that a given value can be safely used with an injection sink - she trusts it does not introduce a vulnerability. That does not imply that the value is indeed safe - that property might be provided by a sanitizer or a validator (that might be used in Trusted Type policies internally; in fact - that's very much a recommended approach).

Clone this wiki locally