Background & Context

We use DOMPurify extensively in a multi tenant web application that serves millions of users. We have also began moving towards TrustedTypes but we find ourselves limited by how the TrustedTypes policy is used within DOMPurify. For starters, we never include DOMPurify via a <script> tag, we always rollup the dependencies in a bundle that is shipped to the browser and is loaded as a <script> tag. Our code is ESM. Additionally, because performance is an influencing factor in our architecture, we use multiple preconfigured instances of DOMPurify in order to skip configuration logic with repeated invocations. The multiple DOMPurify instances have different usages and we'd like to maintain that flexibility in our system. We find that with our current CSP configurations which does not allow duplicates we cannot use more than 1 instance of DOMPurify for the entire application. Given the size of the application and the scenario we are in this affects our ability to maintain our flexibility and, given that with each invocation we need to reset the configuration and the hooks, we end up spending compute cycles that we feel could be avoided.

We would like to request the ability for DOMPurify to support passing in our own TT policy via configuration when instantiated or when the configuration is being set.

Feature

Given a configuration object passed to sanitize or to setConfig allow an entry to specify the TT policy that DOMPurify should use.

I've worked on the DOMPurify source code before and would be happy to contribute if this feature is being accepted.

The new configuration option could be named trustedTypesPolicy and it must define a createHTML hook. The code must validate the object's shape to prevent passing in policies which do not define the minimum requirement.