Understanding Applet Capabilities and Restrictions

Security Restrictions

[CHECK everything on this page.]

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 throws a SecurityException.

Currently, SecurityExceptions never reach the applet. If they did, it'd be easy to write code that tries various ways of accomplishing something, resorting to a "safer" (but less ideal) way if a SecurityException occurs. This isn't much of an issue now, but it will likely become one as the number of applet viewers grows, with each applet viewer having its own SecurityManager implementation.

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

Applets can't load libraries or define native methods.

They 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 can't ordinarily read or write files on the host that's executing it.

The JDK Applet Viewer actually permits some user-specified exceptions to this rule, but Netscape Navigator 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 Communicating with Other Programs to learn how to work with a server-side application.

An applet can't 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 can't start any program on the host that's executing it.

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

An applet can't read every system property.

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.

Understanding Applet Capabilities and Restrictions