Best Practices for Securing Apache Tomcat 7

posted by mthomas on November 2, 2011 07:27 AM

Every effort is made to have each version of Apache Tomcat to ship with a system of reasonable defaults forsecurity purposes. This means that the standard defaults for the security settings are reasonably secure—it is not as secure as it could be, but not horribly insecure either. The default security level is essentially a compromise between security and usability. It is probably OK for simple use in production, but there are a number of things that all users should consider before deploying business applications on a standard installation of Apache Tomcat.

General precautions:

  • Tomcat security configuration should not be your only line of defense. Take a comprehensive look at security and ensure that your OS is secure,there are firewalls in place, and file permissions are set correctly as well.Remember, it won’t matter how secure your application is if your underlying platform is vulnerable. A simple rule of thumb (especially for those firewalls) is to ban everything and only explicitly allow what access you need to run your applications.
  • Delete all the stuff you don’t need. Tomcat will by default install a handful of default applications that you don’t need, and having them in production is just more applications to look after and to ensure are secure. Take a look at the documentation, examples, default root web application, Manager App and Host Manager App and if you are not using them, delete them and focus just on your production applications. While these applications are relatively low risk, eliminating risk is always a better strategy. Same would be true if applications are archived or no longer in use – move them off of the production site to eliminate any additional pathways for threats.
  • Consider running under a Security Manager. This is always a good idea if you are running applications that you do not trust (e.g. a hosting environment), or if you want an additional layer of protection. A Security Manager will essentially run each deployed web application in a separate sandbox to prevent malicious code from accessing your files or other applications on your network. While it is always a good idea to run under a security manager, it should be noted that this is best done during early stages of development as it can impact how an application behaves and thorough testing is always recommended. For later stage projects you’llneed to evaluate if the benefits of a security managerare worth the extra cost of development and testing to deploy it properly. The TCK tests that are used as part of every Tomcat release are always run under a Security Manager but few users run with a Security Manager in production. There is, therefore, a slightly increased risk that you will hit a Tomcat bug running with a Security Manager. However, it is usually possible to configure around such bugs if they occur.


The following all apply to server.xml:

  • Disable the shutdown port. Set the port on the server element to -1 to disable the shutdown port, which means that the only the user who started the instance or root user can shut down the Tomcat server (you can shut Tomcat down safely with a kill -3).
  • Compile the APR/native connector correctly. If you are going to be using the APR/native connector on Solaris, to ensure stability be sure to use the Sun Studio compilers. When compiled with gcc it is known to be unstable.
  • Use the Security Lifecyle Listener. If you are running Linux in general, take advantage of the new Security Lifecycle Listener developed as part of the Tomcat 7 release cycle to further harden your installation. This feature preventsTomcat from running as Root and provides secondary checks to ensure any files created are done so securely.
  • Specify the interface for your connectors. If you want to have your connectors only listening on a particular interface (such as intranet vs internet), use the address attribute of the connector element to specify the interface and it will then limit the amount of potential avenues for threats to come through.
  • Eliminate weak ciphers for using SSL on connectors. By default, Tomcat will use whatever ciphers are on the JVM by default, which usually include some ciphers that are considered weak and insecure. The valid list of ciphers varies according to the provider and JVM policy files that are applied, check your JVM documentation for the correct list and eliminate any additional ciphers.
  • Do not use legacy renegotiation on SSL. The vulnerability CVE-2009-3555 is one where renegotiation handshakes do not properly associate during an existing connection allowing man-in-the-middle attackers to potentially insert malicious data or requests. Updated versions of Tomcat and the JVM correctly avoid this renegotiation handshake problem. If you need to support clients that have not been updated then you may need to reconfigure your application so that the user is authenticated on first connection as that will remove the need for renegotiation. It is not recommended to re-enable legacy renegotiation.
  • Keep your Context with limited access. By default, the Context attributes crossContext and privileged attributes are set to false. crossContext allows a web application to dispatch requests to another application and privileged allows access to Tomcat's internals. Except for trusted applications that require these abilities, these should remain false.
  • Use aliases, not symlinks. Not enabled by default, the allowLinking attribute can allow Tomcat to follow symlinks from within an application to quickly add additional resources for an application to reuse. While the application is running this is ok, however when Tomcat later undeploys an application it will also remove the symlinks as well which another application may rely on and could create instability or possibly a vulnerability. To avoid this, use the new aliases attribute instead which effectively does the same thing as symlinks, but they do not get deleted when you undeploy the app.
  • Configure an AccessLogValve. Tomcat 7 has an AccessLogValve enabled by default, but if you do not have Tomcat 7, it is strongly recommended that you configure one. Oftentimes in the case of an attack this could be the only information you could have on how the attacker got in.
  • Add a RemoteAddrValve for administrative applications. Limit access to administrative applications or other limited access applications with a RemoteAddrValve to reduce access to a specific set of known hosts. This valve relies on IP addresses which are harder to fake, so it is recommended to limit client access by this RemoteAddrValve versus the RemoteHostValve.
  • Use a LockOutRealm. Now standard by default in Tomcat 7, this realm simply protects your application from brute force attacks by locking out the offending account after a number of unsuccessful attempts.


The following apply to system properties:

  • Do not recycle façade objects. Setting the org.apache.catalina.connector.RECYCLE_FACADES system property to true results in each request creating a new façade object instead of recycling an old one. By creating a new object each time you reduce the opportunity for a bug in one application to share data to a request in another. This is setting is often used to work-around vulnerabilities in applications where request and response objects are incorrectly cached between requests.
  • Do not enable non-standard parsing of the URI. Disabled by default, but still in the application for backwards compatibility reasons are two system properties, org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH and org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH, that allow non-standard parsing of the URI. These properties significantly improve your chancesof a directory traversal attack and are therefore strongly recommended to avoid using.

Of course, additional security considerations may apply. In general, if you change any system default, you should check with the official Apache Tomcat security documentation to ensure that your changes will not open up your applications to attack.


Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.


Post new comment

This question is for testing whether you are a human visitor and to prevent automated spam submissions.