Yes, the demand for rich clients and rich-client-like Web applications are definitely overwhelming for its look and feel performance. When we think of rich clients over Web, we often think of applets as a solution in the first place and we forget to consider other promising options like Java Web Start (JWS) and other Web 2.0 interfaces via Ajax and Java Server Faces (JSF). Having said that, I would like to explore your specific concerns related to applet sandbox vulnerabilities!

In most cases I found the common compromises are due to browser-specific vulnerabilities and missing access control policies to its SecurityManager for restricted execution and access to its local file system. Enforcing stringent access control policies (using a policy file) and usage of signed applets are often considered to be best practice options for deploying secure applets. The Java 2 platform introduced the notion of signed applets, which allows signing an applet to ensure an applet’s origin and its integrity are guaranteed by a certificate authority (CA). The signed applet can be trusted to run with the permissions granted in the policy file defining the access control privileges for its execution and local resources. More importantly, it is important to verify your target client browser for any known security vulnerabilities related to Java applet plug-in and its runtime environment.

Although applets are very compelling in a Web environment, I would suggest considering JWS and JSF as two alternative solutions to building applets. JWS is a full-fledged application that allows Java rich-client applications to be deployed, launched and updated from a Web server. The underlying technology of JWS is Java Network Launch Protocol (JNLP), which provides a standard way for packaging and provisioning the Java application (as JAR files) and then launching them over a network. From a security perspective, JWS applications run outside a Web browser using the sandbox features of the local Java Runtime Environment (JRE). JWS also allows defining security attributes using a JNLP descriptor for client-side Java applications and their access to local resources such as file system access, making network connections and so on. JWS also support the use of signing JAR files (similar to applets) in order to verify the application origin and its integrity so that it can be trusted before it is downloaded and executed on the local machine.

JSF is another promising Web client presentation solution runs using a server-side J2EE environment similar to Java Server Pages (JSPs) and servlets, augmented with the power of rich-client like UI components. With JSF, developers can add Asynchronous JavaScript and XML (Ajax) functionality by inserting specialized AJAX/JavaScript technology code. JSF adopts the J2EE Web container security mechanisms to enforce security and controlled access to operations and their underlying resources. The Web container security features include authentication, authorization, secure session handling, transport-layer security, single-sign on access and so forth. For implementation specific details, I would suggest referring to Core Java Server Faces in conjunctiion with Core Security Patterns for supporting design patterns and best practices.