Sandbox the live preview inside an iframe on a separate origin #162

wants to merge 6 commits into


None yet

1 participant


This isn't yet a formal pull request with productionalized code; it's more to begin a dialogue that will take place in mozilla/webpagemaker#626.

The code contained in this pull request is a proof-of-concept which houses the live preview on a separate origin that is communicated with via postMessage. A simple message-passing protocol is defined that treats the preview frame as untrusted, thereby mitigating any attacks that malicious code can inflict on the editor domain.

I've hosted a demonstration of this at There shouldn't be any way to access the editor frame from script that the preview frame executes.

toolness added some commits Nov 14, 2012
@toolness toolness Initial attempt at a sandboxed live preview frame.
This commit adds live-preview-sandbox.js, which is a drop-in replacement
for live-preview.js. It creates the preview frame in a separate origin
and communicates with friendlycode through postmessage.

This is done primarily to prevent malicious code from compromising the

Right now this doesn't work with the preview-to-editor-mapping
component, but it can be made to.

I originally tried using the "sandbox" iframe attribute, which is supported
on webkit and bleeding-edge versions of firefox, but as child iframes
inherit the properties of their sandboxed parent, this proved problematic.
So I just assume that the preview iframe is in a separate origin; by default,
if no alternate origin is passed in, the code assumes it's at port+1 (i.e.,
if the friendlycode instance is at localhost:8001, the sandboxed iframe
is created at localhost:8002). This is currently inconvenient to set up
because it requires running two web servers on different ports.
@toolness toolness allow a custom live preview implementation to be passed into Friendly…
@toolness toolness added sandboxed-alternate-publisher example. 9afdf40
@toolness toolness typo fix c7fb304
@toolness toolness If no sandboxURL is passed in, just use one at our origin. e8cb1cd
@toolness toolness made preview to editor mapping work w/ sandboxed preview. acb8608

It should be noted that I originally tried using the sandbox attribute of <iframe> elements to implement this, so that we wouldn't have to mess with DNS/ports to create authentic separate origins. However, the sandbox created has a universally unique origin, and any of its child iframes also have universally unique, separate origins--which means that user code which creates iframes won't actually work the way a normal webpage does. Combined with the fact that the sandbox attribute isn't even supported on IE9, which we want to support, I didn't pursue this strategy.

That said, we could still benefit from using the sandbox attribute to prevent the child code from loading content to the top-level browsing context (i.e., the editor), as this is definitely something we never want to subject users to.


Note also that this proof-of-concept doesn't yet support the "x-ray goggles" effect of being able to click on an element in the preview page and having its source code highlighted in the editor side. However, this can be done with the right kind of message passing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment