Summary

The JavaScript security model is based on a sandbox approach where scripts run in a restricted execution environment without access to local file systems, user data, or network capabilities. The same-origin policy prevents scripts from one site from reading properties of windows loaded from a different location. The signed script policy allows digitally signed mobile code to request special privileges from the user. This technology guarantees code authenticity and integrity, but it does not guarantee functionality or the absence of malicious behavior. Both major browsers are capable of using signed code, but Internet Explorer unfortunately does not support signed JavaScript. Yet even if perfectly implemented, many users will refuse to grant signed script privileges out of well-founded security fears. As a result, if employed, signed scripts should always be written in a defensive manner to accommodate this possibility, and are probably best suited for intranet environments.

The sad reality is that JavaScript can be used to wreak havoc on the user’s browser and operating system without even violating the security policies of the browser. Simple code that eats up memory or other resources can quickly crash the browser and even the operating system itself. Deceptive programming practices can be employed to annoy or trick the user into actions they might not intend. Yet clean, careful coding does not solve all JavaScript security-related problems. Web applications accepting user input need to be careful to properly validate such data before accepting it, and to sanitize it before writing it into a Web page. Failing to do so can result in cross-site scripting vulnerabilities, which are as harmful as violations of the same origin policy would be. Because of the range of potential problems, it is up to individual developers to take the responsibility to write clean, careful code that improves the user experience and always be on the lookout for malicious users trying to bypass their checks.