This article is a stub. You can help the whatwg.org wiki by expanding it.
iframe sandbox attribute
This page is for collecting issues and proposals related to the new
proposal drop sandbox attribute
The new 'sandbox' feature on
<iframe> should be considered for removal.
In speaking with fellow developers at Mozilla, I've collected the following feedback:
- The sandbox feature and functionality needs a thorough security review.
- It will be a lot of work to implement properly.
- It may not actually solve the problem it is intending to solve.
— Tantek 01:56, 2 August 2010 (UTC)
opinions and discussion
- +1 Tantek Çelik
- -1 Ian Fette
- -1 Adam Barth
- -1 Maciej Stachowiak
- -1 EdwardOConnor - While I'm put off by the syntax (markup in attribute values looks quite gross), I think the feature is needed and the design certainly meets the need.
why sandbox should be kept
Per Maciej, support for the new 'sandbox' feature on
<iframe> is "shipping in current versions of Safari and Chrome."
The initial patch implementing it for WebKit can be seen here: http://trac.webkit.org/changeset/51577.
This patch was 100k, but more than half of it is tests and the ChangeLog entry.
"There's been a lot of security review, both on this list and in the W3C HTML WG. I've been meaning to write up a summary of all the discussion, but I haven't gotten around to it yet. We ended up tweaking a few aspects, but generally the design seems solid." — Adam Barth 2010-08-01
Also from Maciej: Security experts have reviewed it (which security experts? links?). 'sandbox' itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and 'seamless' attribute.
While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable.
examples in the wild
Per Maciej, Content has been built using it.
Which content? URLs to examples in the wild?
- At one point, <iframe sandbox> was used by Google Image Search to prevent framebusting by enframed content. However, I believe it is currently disabled since it prevents plugins from working.
Per Maciej, while it's unclear if <iframe sandbox> will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like:
Examples? Could someone provide code examples of how <iframe sandbox> could be used for gadgets or ads or other use cases?
Not a full worked example, but embeding an gadget like this, in combination with postMessage, is safer than a vanilla iframe:
<iframe sandbox="allow-scripts allow-same-origin" src="http://external.server.com/gadget.html"<</iframe>
It prevents the framed content from being able to navigate the top level, among other things.
If the allow-same-origin flag is left off, then the gadget can even be hosted on the same site as the embedding content, but would still be isolated from DOM access and network access to the site's resources. In this case it would need to be used in combination with srcdoc or with the text/html-sandboxed MIME type to give sound security.
In the link above, we have a way of parsing and storing an AJAX responseText with a sandboxed iframe. This proposal is working around the usage of innerHTML, which is causing problems on iOS/Mobile Safari devices.