Trusted Types are definitely designed with safe-by-construction APIs in mind. A primary use case is to write a safe-by-construction library that internally decl

Trusted Types are definitely designed with safe-by-construction APIs in mind. A primary use case is to write a safe-by-construction library that internally declares and uses a Trusted Types Policy that your CSP headers declare that they trust. If none of the policies in your CSP headers declare a createHTML method, then you can be confident that innerHTML can't be used anywhere in your app. You still want the other policy methods because there are other unsafe sinks in the DOM. For example: const scriptElem = document.createElement('script'); scriptElem.src = someUntrustedInput; document.body.appendChild(scriptElem); // arbitrary code execution! There's a number of these sinks, and they have legit important use cases, but you want to be able to sustainably review all such uses. For example, you could make a Trusted Types policy that will only accept a small number of constants for script urls. That way you can still create script elements to e.g. implement lazy loading of code, but you're certain that those APIs will not be used by an attacker to load unknown code.