The reason behind that is security. If you have
yoursite.com in one window and
gmail.com in another one, then you’d not want a script from yoursite
.com to access or modify your mail or run actions in context of gmail on your behalf.
Windows can work in contexts of each other only if they are from same protocol://domain:port, or, shortly, from same origin.
The document.domain Exception
The highest inconvenience for the Same Origin policy is the thirt-level domains restriction: you can’t access with script the context of pages from different subdomains of the same domain, including www subdomain or http(s) protocol. Agree that this is not cool at all in a cloud era.
Say, we’ve got a window at a http://site.com and two iframes: the first comes from http://john.site.com, and another one comes from http://peter.site.com.
All of them can assign
document.domain property to
site.com, and then the same origin restrictions will be removed.
Note two important features:
- The new
document.domainvalue must be within the same second level domain.You can change
document.domain='site.com'on the page originating from
my.site.com, but can’t do it if the page is at
document.domainshould be assigned on all windows, including the main one. Even if the domain is already
site.com, you still need to assign it:
document.domain = 'domain.com'; would make browser consider those as from the same origin.
HTML5 Sandbox Attribute
With HTML5 specification the iFrames have got a couple of new attributes, one of which, called sandbox, can redefine the origin policies, scripts and forms restrictions. Currently the sandbox property is only supported in gecko and webkit-based modern browsers (including Safari for iOS, but not on Android) and can set the following policies:
If you want to enable forms post back within the IFRAME element, you just specify the allow-formsvalue for the sandbox attribute.
If this value is present, the embedded page is allowed to post back using a form submit within the frame.
By default, an IFRAME page from the same domain has the possibility to access the parent’s document object model.
With the sandbox attribute in place, the page will be treated as not being from the same origin. This page has no access to the resources, even when coming from the same domain.
To re-enable same-origin treatment in a sandboxed scenario, you have to specify the allow-same-origin attribute.
When you use the sandbox attribute, anchor targeting other browsing contexts are ignored and not executed by default. This protects the website hosting the IFRAME content from being replaced by the hosted content.
For example, this link would not be executed in the default sandbox, as the target would replace the complete web page:
Relaxing this policy is only recommended if you trust the content you host.
Sometimes it is useful to allow embedded content opening up new popup windows. A perfect example is a mapping service like Bing Maps.
When embedding Bing Maps, additional functionality like driving directions or destination details can be looked up in popup windows. But since sandbox prohibits this, there’s a setting in Internet Explorer 10 that will enable popups without compromising the sandbox.
The following code shows how to set up ms-allow-popups.
When setting this value, embedded sites are able to display information in a new window.
The property has to be set before the iFrame inner page load or the inner page should be reloaded after the property is changed. However even though allowing multiple scripts in the same sandbox can lead to security vulnerabilities. For example, your hosted content can manipulate the attributes of the sandbox and remove further restrictions though for our purpose we need two properties: allow-same-origin and allow-scripts working together, which means this is not an ideal solution security-wise.
iFrame with sandbox HTML5 attribute example:
<iframe src="http://bielousov.com" sandbox="allow-same-origin allow-scripts allow-forms"></iframe>
All modern browsers support messaging between windows. The topic is very interesting and solid. It is discussed in a separate article Cross-window messaging with postMessage.
IE exceptions to Same Origin policy
Internet Explorer poses two major exceptions.
The first one are so called “Trust Zones”. If both domains are in highly trusted zone, e.g both are corporate domains, then the Same Origin limitation is lifted completely.
The second one is port. Internet Explorer doesn’t include port into Same Origin components, hence the http://site.com and http://site.com:8080 are considered from the same origin and no restrictions are applied.
The exceptions described above are non-standard and not supported in any of other major browsers.