Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • September 9, 2013

New security requirements for RIAs in 7u51 (January 2014)

Guest Author

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements.  Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.


  • You are required to sign all RIAs (Applets and Web Start applications).
  • You are required to set the "Permissions" attribute within the Manifest.
  • Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

Complete information can be found within the Java 7 update 51 release notes (here once 7u51 is released in January 2014).


 As of 7u51, (January 14, 2014), your RIAs must be updated. The updates required are on the packaging and distribution; no API code changes should be required. The impetus for these changes relates to potential re-purposing of sandboxed applications, whereby placing permissions within a signed JAR prevents modification of your specified permission level.
RIAs must contain two things:

  1. Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes.
  2. Manifest Attributes
    1. Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions.
    2. Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g. intranet.example.com).


Manifest-Version: 1.0
Created-By: 1.7.0_51
Permissions: sandbox
Codebase: www.java.com java.com

This manifest file is created when the JAR is packaged, either through the default jar command, your build tool, or your IDE.

Sample JNLP for launching a web start application:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="JavaDetection_applet.jnlp">
        <title>Java Detection</title>
        <vendor>Oracle Inc.</vendor>
        <jar href="JavaDetection.jar" />
          name="Java Detection Applet"
     <update check="background"/>

Some developers may notice that the <security /> element is missing from the above JNLP. By providing it within the cryptographically signed JAR file, it is no longer necessary within the JNLP for Java 7 update 51 (January 2014).

See the Development and Deployment Of Rich Internet Applications for full details of JNLPs and the deployment toolkit. For instructions on signing code, see the tutorial Lesson: Signing Code and Granting It Permissions.

Desktop Administrators

If you are a desktop administrator managing Java installations across a series of computers, consider using Deployment Rule Sets to whitelist your internal applications. Deployment Rule Sets allow you to certify that an application is known to be trusted and safe, even if you cannot update the application to adhere to these requirements.

Join the discussion

Comments ( 10 )
  • Hayden Jones Monday, September 9, 2013

    I am excited by the possibility of using a JavaFX applet in sandbox mode but I have two problems that I would like the JavaFX team to address.

    1) I would like FXML to work in sandbox mode when the items are public. Currently it needs reflection and that violates the sandbox.

    2) I was unable to use the Jersey client because of the logging which violates the sandbox. Perhaps we could have a REST client that does not need logging?


  • costlow Monday, September 9, 2013


    I located and commented on a JavaFX bug about loading FXML from a sandboxed content. The link (account required) is https://javafx-jira.kenai.com/browse/RT-23622#comment-358006

    For Jersey, I didn't find a similar bug in https://java.net/jira/browse/JERSEY/ but the threat model for this sandboxed case would be more in terms of socket access than logging. Are you using the jersey-core-client rather than the whole bundle?

  • guest Wednesday, September 18, 2013

    So this is the killer for our Java projects! Inside a corporate environment it is not possible to know the codebase. Web Start was used to allow easy installation and update of the application using self signed code. So moving to .NET?

  • costlow Wednesday, September 18, 2013

    The Codebase attribute that you’re referencing is optional for the precise reason you mention. Many developers or ISVs do not know this ahead of time, so if you don’t know it, you can leave it off. If you do know the deployment location or domain (e.g. *.intranet.example.com) then providing it will limit where the Web Start applications will run. The Permissions attribute will be required because the application author can readily determine that ahead of time.

  • guest Thursday, September 19, 2013

    Thanks. So I removed the codebase attribute from all used jar files. But this gives "Missing Codebase manifest attribute for: ..." message in console window.

  • Shane Thursday, September 19, 2013

    Looking at the requirements for Codebase and Permissions manifest attributes.

    Will all jars referenced by the applet need to be updated to include the attribute or will it be limited to the jar that contains the applet code? There is a concern that we will have to modify library jars that we do not control.

  • Torsten Kleiber Thursday, September 26, 2013


    Will Oracle Forms deliver new jar Files for this requirements?

    Kind regards


  • javadev Friday, September 27, 2013

    Ridiculous that an applet will need signing only for running in sandbox!

    Flash does not need that, Silverlight neither!

    What is the reasoning behind it besides that Oracle cannot make the sandbox work reliably?

    A lot of very useful unsigned applets (math, physics, etc.) are out there; and they will not run after 7u51 just because "programmers" at Oracle are not able / willing to do their duties?!

    Who will use applets in the future, who will pay for a 1 year certificate 200-300$ (besides maybe the large gaming studios)?

    Shame on you Oracle for killing such a good platform!

  • costlow Monday, September 30, 2013

    There are quite a few great applets out there for math, physics, and other fields. Applications written for this may still be downloaded and executed, or a department within a university can whitelist their RIAs through a Deployment Rule Set.

    While certificates are time-boxed, signed artifacts can be timestamped to allow clients to verify signature beyond the certificate expiration. See the note about timestamps at https://blogs.oracle.com/java-platform-group/entry/code_signing_understanding_who_and

  • guest Tuesday, October 8, 2013

    Even Applets need updates. So a one-year-certificate won't help. In other words, each update of a private Applet or small company will cost $200 because they update maybe once a year.

    So Oracle is forcing those people to use JavaScript on client site. And when their developers start using JavaScript, why not use JavaScript on server site? ECMA-Script for servers is quite good. And when starting to redesign the code why continue to use the Oracle database? Why use a product of a company that made all those redesign necessarry? Maybe use some Google Cloud Database?

    Currently there are 2 groups in a company that decides which database to use: The management ("Oracle, big company, we heared of it") and developers ("Oracle does what I need and works together with my tools"). The later maybe will tell their management that they can also use a cheaper database because they have to use some new language and tools - .net or JavaScript. They support cheaper databases. Management will like that!

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.