Configuring HttpOnly Cookies in Tomcat/Java Web Applications

Security Significance of HttpOnly Cookies and Tomcat Support

HttpOnly Cookies are a critical security feature designed to reduce the risk of cross-site scripting attacks. When a Cookie is marked as HttpOnly, client-side scripts cannot access it via document.cookie, preventing sensitive information from being stolen by malicious scripts. In Java web applications, the session identifier JSESSIONID is the most common Cookie, making its protection essential.

Tomcat provides native support for HttpOnly Cookies starting from specific versions. According to official documentation and changelogs, the HttpOnly feature was first introduced in Tomcat 6.0.19 and Tomcat 5.5.28. Developers can enable this feature through configuration or programmatic means to ensure session Cookie security.

Configuring HttpOnly Cookies via Settings

In Tomcat, there are several methods to enable HttpOnly Cookies. The most straightforward approach is through global configuration in Tomcat's settings. In the conf/context.xml file, you can add the useHttpOnly="true" attribute to the <Context> element, as shown below:

<Context useHttpOnly="true">
...
</Context>

This configuration enables HttpOnly Cookies for all web applications deployed on that Tomcat instance. For application-specific configuration, you can set the same attribute in the corresponding <Context> entry in conf/server.xml. This method is simple and effective for most standard deployment scenarios.

For applications using Servlet 3.0 or later, configuration can also be done via the web.xml file. In web.xml, add the following configuration:

<session-config>
  <cookie-config>
     <http-only>true</http-only>
     <secure>true</secure>
  </cookie-config>
</session-config>

This approach allows developers to control Cookie behavior at the application level, including HttpOnly and Secure flags. The Secure flag ensures that Cookies are only transmitted over HTTPS connections, further enhancing security. Note that this method requires web server support for Servlet 3.0 specification, such as Tomcat 7.0 and above.

Programmatic Setting of HttpOnly Cookies

In some cases, developers may need to set HttpOnly Cookies programmatically, especially for custom Cookies or older Tomcat versions. This can be done using the setHeader method of HttpServletResponse, for example:

response.setHeader("Set-Cookie", "name=value; HttpOnly");

However, for automatically generated JSESSIONID Cookies, more granular handling is required. A common method is to use a Servlet filter to rewrite the Cookie header. Here is an example code snippet demonstrating how to set JSESSIONID as HttpOnly in a filter:

private void rewriteCookieToHeader(HttpServletRequest request, HttpServletResponse response) {
    if (response.containsHeader("SET-COOKIE")) {
        String sessionid = request.getSession().getId();
        String contextPath = request.getContextPath();
        String secure = "";
        if (request.isSecure()) {
            secure = "; Secure"; 
        }
        response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid
                         + "; Path=" + contextPath + "; HttpOnly" + secure);
    }
}

This method dynamically adds the Secure flag by checking if the request is secure, avoiding overwriting this flag in HTTPS sessions. However, note that this programmatic approach may overwrite other Cookies, so it is recommended only for JSESSIONID-only scenarios or with proper extension for multiple Cookies.

Security Considerations and Best Practices

When implementing HttpOnly Cookies, several key security considerations must be addressed. First, ensure not to accidentally overwrite the Secure flag, especially in HTTPS-enabled applications. The Secure flag prevents Cookies from being transmitted over unencrypted HTTP connections, providing dual protection when combined with HttpOnly.

Second, for applications using multiple Cookies, programmatic setting may require handling all Cookies to avoid leaving some unprotected. This increases code complexity and maintenance overhead. Therefore, prioritizing native Tomcat configuration or web.xml configuration is recommended to minimize potential errors.

Additionally, developers should pay attention to Tomcat version compatibility. For versions below Tomcat 6.0.19 or 5.5.28, HttpOnly support may be limited, necessitating upgrades or alternative programmatic solutions. Regular review and testing of Cookie configurations are essential to ensure security policies are correctly implemented.

Finally, combining HttpOnly with other security measures, such as input validation, output encoding, and content security policies, can build a more comprehensive defense system to effectively counter threats like XSS.