May 27, 2000 - Cross-Window Security

May 27, 2000 Cross-Window Security Tips: May 2000 Yehuda Shiran, Ph.D. Doc JavaScript

First line of defense is to keep all interactions within the same domain. For example, a page on www.webreference.com can freely interact through scripting with a any other page on www.webreference.com. The way DHTML Object Model enforces it is by checking the document.domain property. Only pages with identical document.domain are allowed to interact freely. Another basic requirement is for the two document to have the same access protocol. An HTTP page cannot access an HTTPS content, for example.

You can expand the range of permissible access by setting the document.domain property to a suffix of the site name space, up to the second-level domain. A page on www.microsoft.com, for example, can set document.domain to microsoft.com and increase the target population of pages to interact with to include pages in home.microsoft.com, or any other microsoft.com's site. The only condition is that all interacting pages must set their document.domain to an identical value. It is not allowed to go beneath second-level domain names, so "com" is not an option. For international sites, second-level domain names include three elements, as in netscape.co.jp.

Now, don't be confused. The internet is based on the ability to navigate to any URL beyond the original domain, and these types of accesses are always permitted. What is restricted is access that attempts to read out or modify content. The href property, for example, might be assigned to cause navigation, but it cannot be read if the URL is of a different domain. The following table summarizes the restrictions that apply to pages of different domains: