I have been reading about the HTML5 additions to the <iframe>
tag. One of the additions is the inclusion of sandboxing flags that allow the document loaded into the iframe
to interact with its parent browser context.
After reading some of the documentation, I am looking for a bit of clarity. I have read MDN's description of the allow-same-origin
flag:
Allows the content to be treated as being from its normal origin. If this keyword is not used, the embedded content is treated as being from a unique origin.
Not hugely, helpful, I think, after having read W3C's specification:
...[I]t can be used to embed content from a third-party site, sandboxed to prevent that site from opening pop-up windows, etc, without preventing the embedded page from communicating back to its originating site, using the database APIs to store data, etc.
My question is specifically about what MDN refers to as the "normal origin" in light of W3C's specification: when refering to the "normal origin" is MDN stating that the content of document contained within the <iframe>
tag is treated as if it shares the origin of the page from which the document originates, e.g. a YouTube video believes - and can communicate as if - it is still apart of YouTube? Or, does the <iframe>
document have access to the parent browser context?
You can't access the document between an iFrame and the Parent window (from different domains). To communicate between frames in you'd need to use postMessage.
Using the allow-same-origin allows you to use, for example, cookies that are in the iFrame.
Here's a good reading to understand better iFrames' sandbox: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
I was still a bit confused after reading LFC's answer, but the link they provided had a good explanation. Here's a summary:
Let's say we want to add a tweet button to our website. We could just do this:
But we're probably giving twitter more permissions than they need. So we want to sandbox them. Twitter apparently needs to know whether the user is logged in (maybe so they can show your avatar next to the tweet button, for example), so the iframe needs to be able to access
twitter.com
cookies and other data associated withtwitter.com
(local storage, etc.). So by settingallow-same-origin
, we give the iframe permission to use the data fromtwitter.com
.Twitter may also need to make requests to
twitter.com
resources, and these would be treated as cross-origin requests if you didn't setallow-same-origin
, so those requests would probably be blocked by the browser - unless the resources had headers which allowed cross origin requests.