create internal trustedTypes policy only if not specified via config object

[dejang]

Summary

Before #800:

• DOMPurify would attempt to create an internal Trusted Types policy when loaded on the page.
• No possibility to configure the policy used by DOMPurify.

After #800:

• DOMPurify would attempt to create an internal Trusted Types policy when loaded on the page.
• sanitize and setConfig allow switching from the internal policy to a user provided one when TRUSTED_TYPES_POLICY configuration option is passed via the configuration object.

This PR:

• DOMPurify will not attempt to create the internal Trusted Types policy when first loaded on the page.
• The internal policy will be created only the first time when calling sanitize or setConfig if and only if TRUSTED_TYPES_POLICY configuration option is not specified in the configuration object. This maintains behavior prior to support TRUSTED_TYPES_POLICY configuration option #800.
• no change to the behavior introduced in support TRUSTED_TYPES_POLICY configuration option #800.

Background & Context

See #798 for the background discussion.

Note: since the original loadDOMPurify test helper was performing a call to sanitize without any configuration option this triggered the creation of the internal policy and I could not write a test to validate that there is no policy created when supplying TRUSTED_TYPES_POLICY configuration option. I had to refactor the helper to allow writing a new test which specifically looks for the number of policies created when DOMPurify is loaded on the page and after calls to sanitize.

Tasks

• internal Trusted Types policy creation is skipped if configuration object supplies a Trusted Types policy

[tosmolka]

nit: I would move let trustedTypesPolicy declaration just before if (cfg.TRUSTED_TYPES_POLICY) { line

[dejang]

that wouldn't be possible in the present form of the code, the if condition is part of the _parseConfig function and let trustedTypesPolicy is in the upper scope. Moving it before the if would make it a local variable to _parseConfig and inaccessible to the rest of the methods that look for it on the upper scope. This would be a move involved effort.

[tosmolka]

Let's keep current change then if it's intentional.

[tosmolka]

nit: I would revert let emptyHTML = ''; to original declaration before PR 800

const emptyHTML = trustedTypesPolicy ? trustedTypesPolicy.createHTML('') : '';

and move it just after either default or custom trustedTypesPolicy is initialized.

[dejang]

I believe we would be missing some functionality if we make it a const and initialized one time. Particularly this kind of usage:

try {
  DOMPurify.sanitize(dirty1);
} catch(e) {
  DOMPurify.sanitize(dirty1, {TRUSTED_TYPES_POLICY: policy});
}

This would be something that developers can use to detect if their host, which they may not control the configuration of, allows the usage of DOMPurify with TT by default or if they need to declare a policy or even create a new instance of DOMPurify for themselves.

There is, however, an alternative to initializing this. Looking at the existing trustedTypes API in Chrome, there seems to be a trustedTypes.emptyHTML signed value built into the API so this declaration would not be needed anymore. We could simply declare it as

const emptyHTML = trustedTypes? trustedTypes.emptyHTML : ''

I did not want to make that change because I do not have enough information to know if the API is considered stable at the moment and if this will be supported in the future. Should be an easy improvement for a follow up PR in case it is.

[tosmolka]

Let's keep current change then if it's intentional.

[cure53]

Cool, are we ready for a merge? 😊

[dejang]

@cure53 let's do it! I'm ready to upgrade whenever the new release is published.