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 http://www.cert.org/tech_tips/malicious_code_mitigation.html.

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.