JavaScript® Programmer's Reference

Chapter 17. JavaScript Security

The browser is one of the most rigidly controlled development environments you can imagine. It has to be this way. Neither Microsoft nor Netscape really ever trusted the web. They also know that if users ever develop a legitimate fear of surfing for what a web page could do to their computer, that browser would be dumped faster than you can say "Firefox." In an intense browser war that's lasted for a decade, it's natural for vendors to be cautious about rolling out new features and capabilities. No wonder it took years for Ajax to take off. Still, the browser has a long and unfortunate history of security holes that for a long time gave JavaScript a bad reputation, partly deserved, partly wrongly attributed. There's some stability now, but the rules for developers are constantly changing. Mostly these changes are subtle refinements to a fairly coherent security policy that has been adopted more or less across the board. This chapter introduces the main issues in browser-based JavaScript security, including the Same Origin Policy, signed scripts, policies and zones, and miscellaneous other issues to be aware of.

Security Models

For any embedded scripting technology in a web page like Flash, Silverlight, or JavaScript, the vendor does a balancing act between freedom for the developer (and consequently for the user) and security. There are two ways to go with it too: Either warn the user every single time a page uses scripting, or just limit the functionality ...