Understanding Applet Capabilities and Restrictions

Security Restrictions

One of the main goals of the Java environment is to make browser users feel secure running any applet. To achieve this goal, we've started out conservatively, restricting capabilities perhaps more than necessary. As time passes, applets will probably get more and more abilities.

This page tells you about the current applet security restrictions, from the point of view of how they affect applet design. For more information on applet security, you should refer to Marianne Mueller's excellent document:

Frequently Asked Questions - Applet Security

Each applet viewer has a SecurityManager object that checks for applet security violations. When a SecurityManager detects a violation, it creates and throws a SecurityException object. Generally, the SecurityException constructor prints a warning message to the standard output. An applet can catch SecurityExceptions and react appropriately, such as by reassuring the user and by resorting to a "safer" (but less ideal) way of accomplishing the task.

Some applet viewers swallow some SecurityExceptions, so that the applet never gets the SecurityException. For example, the JDK Applet Viewer's implementation of the AppletContext getApplet and getApplets methods simply catches and ignores any SecurityExceptions. The user can see an error message in the standard output, but at least the applet gets a valid result from the methods. This makes some sense, since getApplets should be able to return any valid applets it finds, even if it encounters invalid ones. (The Applet Viewer considers an applet valid if it's loaded from the same host as the applet that's calling getApplets.)

To learn about security managers and the kinds of security violations they can check for, see Introducing the Security Manager.

As the applet overview lesson mentioned, existing applet viewers (including Web browsers) impose the following restrictions:

Applets cannot load libraries or define native methods.

Applets can use only their own Java code and the Java API the applet viewer provides. At a minimum, each applet viewer must provide access to the API defined in the java.* packages.

An applet cannot ordinarily read or write files on the host that is executing it.

The JDK Applet Viewer actually permits some user-specified exceptions to this rule, but Netscape Navigator 2.0, for example, does not. Applets in any applet viewer can read files specified with full URLs, instead of by a filename. A workaround for not being to write files is to have the applet forward data to an application on the host the applet came from. This application can write the data files on its own host. See Working with a Server-Side Application for more examples.

An applet cannot make network connections except to the host that it came from.

The workaround for this restriction is to have the applet work with an application on the host it came from. The application can make its own connections anywhere on the network. See Using a Server to Work Around Security Restrictions for an example.

An applet cannot start any program on the host that is executing it.

Again, an applet can work with a server-side application instead.

An applet cannot read certain system properties.

See Reading System Properties for more information.

Windows that an applet brings up look different than windows that an application brings up.

Applet windows have some warning text and either a colored bar or an image. This helps the user distinguish applet windows from those of trusted applications.

The following figures show a window brought up by a program that can run either as an applet or as an application. The first figure shows what the window looks like when the program is run as an application on the Solaris platform. The second figure shows the window when the program runs as an applet within the Solaris Netscape Navigator 2.0 browser.

As you can see, the applet window has a warning.

Understanding Applet Capabilities and Restrictions