HTMLIFrameElement.srcdoc - takes trusted types #41459
Open
+115
−4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hamishwillee
requested review from
sideshowbarker
and removed request for
a team
github-actions
bot
added
Content:WebAPI
hamishwillee
changed the title
hamishwillee
commented
Oct 10, 2025
|
Preview URLs Flaws (6)Note! 1 document with no flaws that don't need to be listed. 🎉 URL:
External URLs (1)URL:
|
29 tasks
| If the frame is not sandboxed using the Content Security Property (CSP) [`sandbox` directive](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/sandbox) (or is sandboxed but includes the [`allow-same-origin`](/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/sandbox#allow-same-origin) value) then it will be same-origin with the parent. | ||
| This means that the frame will have complete access to the parent DOM and resources, and visa versa. | ||
|
|
||
| This is a very significant vector for [Cross-site-scripting (XSS)](/en-US/docs/Web/Security/Attacks/XSS) attacks if potentially unsafe strings provided by a user injected into a frame without first being sanitized. |
There was a problem hiding this comment.
Suggested change
| This is a very significant vector for [Cross-site-scripting (XSS)](/en-US/docs/Web/Security/Attacks/XSS) attacks if potentially unsafe strings provided by a user injected into a frame without first being sanitized. | |
| This is a very significant vector for [Cross-site-scripting (XSS)](/en-US/docs/Web/Security/Attacks/XSS) attacks if potentially unsafe strings provided by a user are injected into a frame without first being sanitized. |
| This means that the frame will have complete access to the parent DOM and resources, and visa versa. | ||
|
|
||
| This is a very significant vector for [Cross-site-scripting (XSS)](/en-US/docs/Web/Security/Attacks/XSS) attacks if potentially unsafe strings provided by a user injected into a frame without first being sanitized. | ||
| Consider the following code where a string of HTML from a user might be passed into a frame, that is then added to the document. |
There was a problem hiding this comment.
Suggested change
| Consider the following code where a string of HTML from a user might be passed into a frame, that is then added to the document. | |
| Consider the following code where a string of HTML from a user might be passed into a frame that is then added to the document. |
| ``` | ||
|
|
||
| If the frame is not expected to need access to your parent document, you can significantly mitigate the risk by using a CSP sandbox without the `allow-same-origin` value. | ||
| The frame will then be treated as a cross-origin resource, and and attacks will be significantly restricted. |
There was a problem hiding this comment.
Suggested change
| The frame will then be treated as a cross-origin resource, and and attacks will be significantly restricted. | |
| The frame will then be treated as a cross-origin resource, and attacks will be significantly restricted. |
| ``` | ||
|
|
||
| Next we create a {{domxref("TrustedTypePolicy")}} that defines a {{domxref("TrustedTypePolicy/createHTML", "createHTML()")}} for transforming an input string into {{domxref("TrustedHTML")}} instances. | ||
| Commonly implementations of `createHTML()` use a library such as [DOMPurify](https://github.com/cure53/DOMPurify) to sanitize the input as shown below: |
There was a problem hiding this comment.
Suggested change
| Commonly implementations of `createHTML()` use a library such as [DOMPurify](https://github.com/cure53/DOMPurify) to sanitize the input as shown below: | |
| Commonly, implementations of `createHTML()` use a library such as [DOMPurify](https://github.com/cure53/DOMPurify) to sanitize the input, as shown below: |
| ``` | ||
|
|
||
| > [!WARNING] | ||
| > While you can directly assign a string to `srcdoc` this is a [security risk](#security_considerations) if the string to be inserted might contain potentially malicious content. |
There was a problem hiding this comment.
Suggested change
| > While you can directly assign a string to `srcdoc` this is a [security risk](#security_considerations) if the string to be inserted might contain potentially malicious content. | |
| > While you can directly assign a string to `srcdoc`, this is a [security risk](#security_considerations) if the string to be inserted might contain potentially malicious content. |
sideshowbarker
approved these changes
Oct 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HTMLIFrameElement.srcdocnow takes TrustedHTML. This updates the docs using similar patterns to theElement.innerHTMLdocs.Related docs work can be tracked in #37518 (comment)