Home arrow JavaScript arrow Page 2 - JavaScript Security

JavaScript Security

JavaScript has a long and inglorious history of atrocious security holes. Its security problems are not limited to implementation errors. There are numerous ways in which scripts can affect the user’s execution environment without violating any security policies. This chapter examines the security policies browsers enforce on JavaScript embedded in Web pages. (From JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider McGraw-Hill/Osborne, ISBN: 0072253576.)

Author Info:
By: McGraw-Hill/Osborne
Rating: 4 stars4 stars4 stars4 stars4 stars / 107
October 04, 2004
  1. · JavaScript Security
  2. · Exceptions to and Problems with Same-Origin Policy
  3. · Signed Scripts in Mozilla Browsers
  4. · Signed Script Practicalities
  5. · Security Zones in Internet Explorer
  6. · ActiveX Controls
  7. · Browser Security Problems with JavaScript
  8. · Cross-Site Scripting
  9. · Preventing Cross-Site Scripting

print this article

JavaScript Security - Exceptions to and Problems with Same-Origin Policy
(Page 2 of 9 )

Exceptions to the Same-Origin Policy

Modern browsers enforce the same-origin policy on nearly all the properties and methods available to JavaScript. The few useful unprotected methods and properties are listed in Table 22-2. The fact that these are unprotected means that you can access them in another window even if the page in that window was loaded from a different domain. As you can see, none of the unprotected methods or properties permit manipulation of page content or snooping of the sort users should be worried about; they’re primarily navigational.

Note Old browsers often have significantly more exceptions to the same-origin policy than do modern browsers. This is sometimes by design, but more often by mistake. You can find information about same-origin policy enforcement in older Netscape 4.x browsers at

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.

Method/Property Exception
Not subject to same origin policy in most browsers.
window.location Setting this property is not subject to same origin policy in most browsers.
window.open() Not subject to same origin policy in Internet Explorer.
history.forward(), history.back(), Not subject to same origin policy in Mozilla and
history.go() Netscape browsers.

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.

Note Internet 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.

McGraw-Hill-OsborneThis chapter is from JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider, McGraw-Hill/Osborne, ISBN: 0072253576). Check it out at your favorite bookstore today.

Buy this book now.

blog comments powered by Disqus

- Project Nashorn to Make Java, JavaScript Wor...
- JavaScript Virus Attacks Tumblr Blogs
- Google Releases Stable Dart Version, JavaScr...
- Khan Academy Unveils New JavaScript Learning...
- Accessing Nitro? There`s an App for That
- JQuery 2.0 Leaving Older IE Versions Behind
- Fastest JavaScript Engine Might Surprise You
- Microsoft Adjusting Chakra for IE 10
- Brendan Eich: We Don`t Need Google Native Cl...
- An Overview of JavaScript Statements
- An Overview of JavaScript Operators
- Overview of JavaScript Variables
- More of the Top jQuery Social Plugins
- The Top jQuery Social Plugins
- More of the Top jQuery Slider Plugins

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials