Support configurable TrustedTypes policy

[dejang]

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.

[cure53]

Thank you, that sounds like a very interesting and relevant feature and we'd be happy to review a PR implementing it.

[dejang]

Great, I'll get a PR ready for you to review.

[cure53]

The PR looks great, thanks, tests are all green as far as I can see. Ready for a new 3.x release? 😊

[tosmolka]

@dejang , I know this is already merged but if I do read the PR correctly then DOMPurify will now always attempt to create default TT policy (dompurify + suffix) even if the new TRUSTED_TYPES_POLICY option is set.

Would you mind minor refactoring to reverse the order and create default policy only if option is not set (or maybe if its invalid)?

Again, if I read it right, current behavior will cause unnecessary CSP violations when DOMPurify fails to create duplicate default policy on every bundle load. Thanks.

[cure53]

Hmmm, good point @tosmolka! We will wait with a release until clarified & resolved.

[dejang]

Yes, I maintained the existing behavior but I can move the instantiation of the policy.

[dejang]

@tosmolka, hopefully I understood correctly your ask, I'm linking the PR here #801. Let me know if we need to make adjustments. But if everything looks good I am ready to upgrade on my side.

[tosmolka]

Thank you @dejang for quick update, PR looks good to me, I left only minor comments.

[cure53]

Heya, did the latest release address the issue as expected? 😄

[dejang]

Yes, it worked as expected! Thank you for the support and please accept my apologies for getting back to you so late, we only had time to integrate the new version over the weekend.