JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Security Guide
search filter icon
search icon

Document Information


1.  Administering System Security

2.  Administering User Security

3.  Administering Message Security

4.  Administering Security in Cluster Mode

5.  Managing Administrative Security

6.  Running in a Secure Environment

Determining Your Security Needs

Understand Your Environment

Hire Security Consultants or Use Diagnostic Software

Read Security Publications

Installing GlassFish Server in a Secure Environment

Enable the Secure Administration Feature

Remove Unused Components

Removing Installed Components

Procedure To Remove an Installed Component

Remove Services You Are Not Using

Run on the Web Profile if Possible

Securing the GlassFish Server Host

Securing GlassFish Server

Securing Applications

7.  Integrating Oracle Access Manager


Securing Applications

Although much of the responsibility for securing the GlassFish Server resources in a domain fall within the scope of the server, some security responsibilities lie within the scope of individual applications. For some security options, GlassFish Server enables you to determine whether the server or individual applications are responsible. For each application that you deploy in a production environment, review the items in the following table to verify that you have secured its resources.

Table 6-3 Securing Applications

Security Action
Use JSP comment tags instead of HTML comment tags.
Comments in JSP files that might contain sensitive data and or other comments that are not intended for the end user should use the JSP syntax of <%/* xxx */%> instead of the HTML syntax <!-- xxx -->. The JSP comments, unlike the HTML comments, are deleted when the JSP is compiled and therefore cannot be viewed in the browser.
Do not install uncompiled JSPs and other source code on the production machine.
Always keep source code off of the production machine. Getting access to your source code allows an intruder to find security holes.

Consider precompiling JSPs and installing only the compiled JSPs on the production machine. To do this, set the deploy subcommand -precompilejsp option to true for the component.

When set to true, the deploy and redeploy subcommands -precompilejsp option compiles JSPs during deploy time. If set to false (the default), JSPs are compiled during runtime.

Configure your applications to use SSL.
Set the transport-guarantee to CONFIDENTIAL in the user-data-constraint element of the web.xml file whenever appropriate.
Examine applications for security.
There are instances where an application can lead to a security vulnerability.

Of particular concern is code that uses Java native interface (JNI) because Java positions native code outside of the scope of Java security. If Java native code behaves errantly, it is only constrained by the operating system. That is, the Java native code can do anything GlassFish Server itself can do. This potential vulnerability is further complicated by the fact that buffer overflow errors are common in native code and can be used to run arbitrary code.

If your applications contain untrusted code, enable the Java security manager.
The Java security manager defines and enforces permissions for classes that run within a JVM. In many cases, where the threat model does not include malicious code being run in the JVM, the Java security manager is unnecessary. However, when third parties use GlassFish Server and untrusted classes are being run, the Java security manager may be useful. See Enabling and Disabling the Security Manager in Oracle GlassFish Server 3.1 Application Development Guide.
Replace HTML special characters when servlets or JSPs return user-supplied data.
The ability to return user-supplied data can present a security vulnerability called cross-site scripting, which can be exploited to steal a user's security authorization. For a detailed description of cross-site scripting, refer to "Understanding Malicious Content Mitigation for Web Developers" (a CERT security advisory) at

To remove the security vulnerability, before you return data that a user has supplied, scan the data for HTML special characters. If you find any such characters, replace them with their HTML entity or character reference. Replacing the characters prevents the browser from executing the user-supplied data as HTML.