Exceptions to the Same-Origin Policy
You have a bit of leeway with the same-origin policy if you’re working with documents loaded from different servers within the same domain. Setting the domain property of the Document in which a script resides to a more general domain allows scripts to access that domain without violating the same-origin policy. For example, a script in a document loaded from www.myhost.example.com could set the domain property to “myhost.example.com” or “example.com”. Doing so enables the script to pass origin checks when accessing windows loaded from “myhost.example.com” or “example.com”, respectively. The script from www.myhost.example.com could not, however, set the domain to a totally different domain such as google.com or moveon.org.
Problems with the Same-Origin Policy
The same-origin policy is very important from a user-privacy perspective. Without it, scripts in active documents from arbitrary domains could snoop not only the URLs you visit, but the cookies for these sites and any form entries you make. Most modern browsers do a good job of enforcing this policy, but older browsers did not.
Not subject to same origin policy in most browsers.
Setting this property is not subject to same origin policy in most browsers.
Not subject to same origin policy in Internet Explorer.
Not subject to same origin policy in Mozilla and
TABLE 22-2 Some Properties and Methods Are Not Subject to the Same-Origin Check.
Aside from poor enforcement by early browsers, the same-origin policy has another problem. Consider that one Web server often hosts numerous sites for unrelated parties. Typically, a URL might look like this:
But by the rules of the same-origin policy, a script loaded from
would be granted full access to the http://www.domain.com/account pages if they are present in accessible windows. This occurrence might be rare, but it is a serious shortcoming. There’s really not much one can do to protect against this problem.
Another issue with the same-origin policy is that you can’t, in general, turn off its enforcement. You might wish to do this if you’re developing a Web-based application for use on your company’s intranet, and you’d like application windows from different internal domains to be able to cooperate. To work around this restriction in Internet Explorer, you generally have to install a custom ActiveX control in the browser. In Netscape and Mozillabased browsers, you can configure custom security policies or use “signed scripts,” the topic of our next section.
NoteInternet Explorer 5 allowed sites in the “Trusted” security zone to ignore the same-origin policy. However, Internet Explorer 6 does not provide this feature, so you shouldn’t rely on it.