Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

About Cross-Frame Scripting and Security

Note  As of December 2011, this topic has been archived and is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Windows Internet Explorer, see Internet Explorer Developer Center.

With Dynamic HTML (DHTML), content in different windows and frames can interact in powerful ways by scripting with the object model. However, since a browser can simultaneously display unrelated documents in its various windows and frames, certain rules must be enforced to protect data integrity and privacy of information.

This article describes how and why these restrictions apply in the DHTML Object Model. All rules about script interaction apply equally to windows, dialog boxes, frame sets, frames, and iframes.

For most content, only interactions with content from the same domain are allowed. For example, a typical page on www.microsoft.com can freely script content on any other page on www.microsoft.com, but cannot script to pages that are located on a different Web domain. The DHTML Object Model uses the document.domain property to enforce this restriction: only pages with identical domain properties are allowed free interaction. The protocol of the URL must also match. For instance, an HTTP page cannot access HTTPS content.

The range of permissible access for a page can be expanded when a script assigns the document.domain property to a suffix of the site name space, up to the second-level domain. For example, a page on www.microsoft.com can assign the document.domain property—initially www.microsoft.com—as microsoft.com to broaden access to include pages in home.microsoft.com or any other site, as long as the other pages also set the document.domain property to the identical value. Since only pages from a site whose name ends with microsoft.com will permit this domain to be set, it is assured that content from the same provider mutually agrees to interact and is free to do so. Domain suffixes shorter than the second-level domain (such as just "com") are not allowed, because they expose beyond a single provider. For international site names, such as www.microsoft.co.jp, the second-level domain for widest access would be "microsoft.co.jp" (not "co.jp").

Since it is important to be able to navigate windows or frames to any URL beyond the domain restriction, these types of accesses are always permitted. Only access that attempts to read out or modify content is restricted. For instance, the href property might be assigned to cause navigation to occur, but this property cannot be read if the URL is of a different domain. This would allow one page to learn where the user has been browsing, and to allow this is a breach of the user's privacy. Some restrictions that apply to pages of different domains include:

window.location.href Property can be set to navigate, but cannot be read.
Other window.location.href Functionality is blocked.
document.location.href Property can be set to navigate, but cannot be read.
Other document.location.href Functionality is blocked.
iframe.src Property can be set to navigate, but cannot be read.

 

Scripts that attempt to access parts of the object model to which they do not have access are blocked with a "permission denied" error.

While domain security can prevent certain types of content interaction, it is important to understand that this restriction is necessary to ensure security. For example, without domain security, a rogue page could "snoop" on another page or, using DHTML, manipulate its content.

Related topics

Information on Cross-Site Scripting Security Vulnerability
When Output Turns Bad: Cross-Site Scripting Explained

 

 

Show:
© 2014 Microsoft