Security policy (Definition)

The rules about what can access local client-side resources.

The basic approach to security in JavaScript is to disallow anything that might be risky, which is quite straightforward in the context of a web browser. However, there are ways to work around this with signed scripts and calls to Java applets and ActiveX controls which may or may not be secure and in any case are platform dependent.

JavaScript is now beginning to be used outside the browser and so scripts may be executed in all kinds of contexts:

Each of these has its own needs and limitations regarding security so there is not one overall approach that works everywhere but rather a variety of techniques that apply on a platform by platform basis. This means that particular fragments of script may work in one context but not in another.

In the browser, all networking capabilities are disabled. This is not so with some of the stand-alone or some of the command line shell environments where JavaScript may run.

In Netscape 2, the security was very lax allowing JavaScript to send mail purporting to be from another user.

Netscape 3 improved security while version 4 is built around a complete new security model.

MSIE supports different security models, in particular the Authenticode model that allows for signed ActiveX objects to be used.

See also:.jar, <SCRIPT ARCHIVE="...">, <SCRIPT SRC="...">, AuthentiCode, Code signing, Data-tainting, Document.domain, Document.links[], Global object, https: URL, Netscape Enterprise Server, Restricted access, Same origin, snews: URL, telnet: URL, UniversalBrowserAccess, UniversalBrowserRead, UniversalBrowserWrite, UniversalFileRead, UniversalPreferencesRead, UniversalPreferencesWrite, UniversalSendMail