Verify script enforcement applies even if the source text is modified before require-trusted-types-for 'script' is set.

[fred-wang]

Current spec [1] essentially caches the "script text" associated to a script element: it is initially empty and updated by various APIs calls. The "prepare the script element" algorithm is modified [2], so that "child text content" would go through the default policy if it does not match the cached "script text" [3].

Script enforcement could be alternatively be implemented by flags [4]. In that case, it might be tempting not to update the flags when the API calls modifying a script are performed before Trusted Types are actually enforced, with the rationale that these API calls are not considered untrusted at that time. For a cache-based implementations, this would be equivalent to not caching the "script text" until the first time it is set in a context when Trusted Types is enforced.

However, WebKit and Chromium follow the spec and really try and run the default policy on the script text, even if the script text was modified before TrustedTypes enforcement got enabled. This PR adds a test to verify this behavior for HTML and SVG scripts.

[1] https://w3c.github.io/trusted-types/dist/spec/#enforcement-in-scripts
[2] https://w3c.github.io/trusted-types/dist/spec/#slot-value-verification
[3] https://w3c.github.io/trusted-types/dist/spec/#prepare-the-script-text
[4] w3c/trusted-types#579

[fred-wang]

cc @smaug---- @otherdaniel

[smaug----]

Yeah, the spec is a bit silly here. If the script was modified before require-trusted-types-for, why would it be considered not-trusted. But perhaps not worth to change it now.

[fred-wang]

Yeah, the spec is a bit silly here. If the script was modified before require-trusted-types-for, why would it be considered not-trusted. But perhaps not worth to change it now.

On the other hand, when the require-trusted-types-for 'script' is initially present but removed before insertion, then I believe we would not run the default policy (whether or not we decide to check the CSP when modifying the script text). So there is some kind of consistency to only check the CSP just before running the script.

[fred-wang]

Yeah, the spec is a bit silly here. If the script was modified before require-trusted-types-for, why would it be considered not-trusted. But perhaps not worth to change it now.

On the other hand, when the require-trusted-types-for 'script' is initially present but removed before insertion, then I believe we would not run the default policy (whether or not we decide to check the CSP when modifying the script text). So there is some kind of consistency to only check the CSP just before running the script.

(Probably I should add a similar test when the require-trusted-types-for is initially present and removed)

[fred-wang]

Yeah, the spec is a bit silly here. If the script was modified before require-trusted-types-for, why would it be considered not-trusted. But perhaps not worth to change it now.

On the other hand, when the require-trusted-types-for 'script' is initially present but removed before insertion, then I believe we would not run the default policy (whether or not we decide to check the CSP when modifying the script text). So there is some kind of consistency to only check the CSP just before running the script.

(Probably I should add a similar test when the require-trusted-types-for is initially present and removed)

OK, I stand corrected. If we remove the require-trusted-types-for meta tag then TT enforcement still applies per https://www.w3.org/TR/CSP3/#meta-element ; I added tests to verify that.

[lukewarlow]

Could you add a test for module scripts too, just in case they're processed differently to classic ones?