HTMLScriptElement.text - trustedTypes for scripts#41128
Conversation
|
Preview URLs Flaws (7)URL:
(comment last updated: 2025-09-19 01:16:24) |
| ### text vs textContent vs innerText | ||
|
|
||
| The `text` and {{domxref("HTMLScriptElement.textContent", "textContent")}} properties of `HTMLScriptElement` are equivalent: both can be set with a string or a `TrustedScript` type and both return a string representing the content of the script element. | ||
| The main difference is that {{domxref("Node.textContent", "textContent")}} is also defined on {{domxref("Node")}} and can be used with other elements to set their content with a string. | ||
|
|
||
| {{domxref("HTMLScriptElement.innerText", "innerText")}} will generally set and execute the text in the same as the other methods, but may return a slightly different value. | ||
| The reason for this is that this property is designed for getting the rendered text of a string of HTML markup. | ||
| When setting the value the text is treated as a text node, which normalizes the string as if it were visible text (collapsing spaces and converting `\n` to line breaks). | ||
| This does not change the execution of the text, but it does alter the text that is stored and returned. |
There was a problem hiding this comment.
text used to be the script-specific way to set/get the text. There was also inherited innerText and textContent. These two are now implemented in the interface https://w3c.github.io/trusted-types/dist/spec/#enforcement-in-scripts - they are all very similar but there is a subtle difference for innerText. I thought this might clarifya bit for those that are interested.
| You can mitigate these issues by always assigning {{domxref("TrustedScript")}} objects instead of strings, and [enforcing trusted type](/en-US/docs/Web/API/Trusted_Types_API#using_a_csp_to_enforce_trusted_types) using the [`require-trusted-types-for`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/require-trusted-types-for) CSP directive. | ||
| This ensures that the input is passed through a transformation function, which has the chance to [sanitize](/en-US/docs/Web/Security/Attacks/XSS#sanitization) or reject the text before it is injected. | ||
|
|
||
| The behavior of the transformation function will depend on the specific use case that requires a user provided script. |
There was a problem hiding this comment.
Wasn't entirely sure what to say here. The fact is that you shouldn't generally be taking untrusted strings and injecting them directly into scripts. If you do then using trustedScripts is a good idea, but it is impossible to provide general guidance for something that you would only be doing in extreme circumstances. I've tried to lock it down a bit and give some flavour of the risk in the avoidance suggestions.
wbamberg
left a comment
There was a problem hiding this comment.
looks great, just some little things.
Co-authored-by: wbamberg <will@bootbonnet.ca>
|
Thanks @wbamberg - I accepted all the suggestions. |
This updates the TrustedType documentation for
HTMLScriptElement.textso that it includes boilerplate and security considerations.Note that this links to
HTMLScriptElement.textContentandHTMLScriptElement.innerTextwhich are not yet defined. These were inherited from node/Element but are now in IDL - see https://w3c.github.io/trusted-types/dist/spec/#enforcement-in-scriptsSome comments by way of explanation/discussion inline.