Webstudio's use of iframes and security considerations
Webstudio's use of iframes and security considerations
At a glance
The community members are discussing the use of iframes in the Webstudio codebase. The original poster is curious about why iframes were chosen over Shadow DOM, and how Webstudio ensures the security of the iframes, especially from browser extensions or injected scripts. The community members explain that iframes are used only in the builder, and that Shadow DOM is not suitable for encapsulating an entire document. They also acknowledge that protecting against browser extensions is challenging, as many extensions can interfere with the iframe content. One community member suggests exploring a virtual DOM approach to isolate the real DOM from direct user interaction, but another indicates that this is already how it works, though it still doesn't entirely help. There is no explicitly marked answer in the discussion.
Hi @Oleg Isonen I’m a developer and i was going through the Webstudio codebase on GH and I noticed that Webstudio uses iframes for rendering websites. I was wondering what made you choose iframes over something like Shadow DOM? And how does Webstudio keeps the iframe secure, especially from things like browser extensions or injected scripts? Are there any code pointers or documentation you’d recommend for understanding the decision? I’d really appreciate any insights you can share!
Ah, that makes sense. My main concern is protecting the iframe content from things like browser extensions injecting scripts or altering dom. eg, how do you prevent external mutations while still allowing user interactions? Is there a specific strategy that is being used for these scenarios that I am missing?
E.g., when the user edits an input field inside the builder, how are the cases handled where text-editing extensions like Grammarly might try to interact with or modify the iframe content?
Oh ok. Have you thought of exploring an idea where a virtual DOM could act as a middle layer? like between user interactions and the iframe's real DOM. e.g, when a user edits a text field, the input could first be processed in the virtual DOM, and then the updated content is rendered into the iframe. This way, the real DOM stays isolated from direct user interaction, theoretically minimizing interference.
