Is your Tomcat Secure?


Apache Tomcat is the perfect application server for deploying your web applications in production. In fact, it also happens to be the only Java application server that has hardening guidelines published by Center for Internet Security (CIS). CIS publishes hardening guidelines for widely used software to help enterprises protect their deployments. The very fact that they have hardening guidelines for Tomcat is a testament to its widespread popularity and usage.

So, how do you know if your Tomcat installation is secure? Its actually very easy. I will provide step-by-step instructions on evaluating whether your Tomcat is secure. If you find that you need to make changes, you can use Tcat Server to harden your Tomcat instance.

Step 1: Get coffee. Yes, you will need it, because you will be reading a 56-page report.
Step 2: Download the hardening guidelines for Apache Tomcat from Center for Internet here. (Look for Apache Tomcat Server under Applications.)
Step 3: Follow each step and instructions starting on page 9.
Step 4: Do the audit steps and find your deviation from hardening guidelines.
Step 5: Follow the remediation advice and if applicable to your environment, apply the remediation steps.

As you go through this process, you might have realized that the majority of work is in editing server.xml, web.xml, and For example:

1.4.5 Disable client facing Stack Traces (Level 1, Scorable)
When a runtime error occurs during request processing, Apache Tomcat will display debugging information to the requestor. It is recommended that such debug information be withheld from the requestor.
Debugging information, such as that found in call stacks, often contains sensitive information that may useful to an attacker. By preventing Tomcat from providing this information, the risk of leaking sensitive information to a potential attacker is reduced.
Perform the following to prevent Tomcat from providing debug information to the requestor during runtime errors:
1. Create a web page that contains the logic or message you wish to invoke when encountering a runtime error. For example purposes, assume this page is located at /error.jsp.
2. Add a child element, <error-page>, to the <web-app> element, in the $CATALINA_HOME/conf/web.xml file.
3. Add a child element, <exception-type>, to the <error-page> element. Set the value of the <exception-type> element to java.lang.Throwable.
4. Add a child element, <location>, to the <error-page> element. Set the value of the <location> element to the location of page created in #1.

How do you edit these configuration files? You have a few options. Option 1 is to manually log in to each box running Tomcat and edit these files manually. Option 2 is to use the Tcat Server console to navigate to each server and edit these files all within the console. Option 2 is easier than Option 1, but it still requires you to do some repetitive work – well, lets leave repetitive work to others.

Option 3 is the best way, as it avoids repetitive work for the majority of changes you need to make. So, whats the secret? Use Tcat Server and create a configuration profile. A configuration profile holds environment variables and configuration files together. You create a profile and apply it to all the Tomcat server instances that you want to harden. Creating a profile is a simple process, as described by Jason in this post. Applying the profile to servers is even easier, as you just select the profile from a drop-down box and click Save.

If you follow these instructions and harden your Tomcat instances, next time an auditor or your information security officer walks into your office demanding that you prove the security of your infrastructure, you can just point them to the profile and show them the settings. And yes, while others running heavy-weight legacy Java EE app servers are sweating and swearing at the auditors, you could relax and get back to doing more productive things. Like drinking coffee.

You can download Tcat Server here. It’s free to download and use in development and pre-production.

We'd love to hear your opinion on this post

4 Responses to “Is your Tomcat Secure?”

  1. Tcat server is not Tomcat. Why do your titles of your blog say Tomcat but your blog entry reference features in Tcat?

  2. Nice hint, will try to have a peek at it int the future. A few things should be mentioned.

    1) If you click on the Tomcat link, you will be directed to a page where you can select which downloads you want. Tomcat is NOT directly referenced. It is available within the Apache Benchmarks Downloads Suite though. Why there are no direct links in the first place, I dont’ understand.

    2) You don’t have to leave your information to get the files.

    3) The download page doesn’t render properly in Google Chrome (at least for me). had to open it in Firefox.

  3. Thanks John and Oliver for your comments.

    John, the hardening guidelines are applicable to Apache Tomcat. You can harden your Tomcat instances manually. Tcat Server, which is 100% unmodified Apache Tomcat, provides enterprise features that make it much more easier and efficient to make configuration changes to harden multiple Tomcat instances at once. Thus, the reference to Tcat Server.


    The hardening guidelines are hosted by Center for Internet Security, and they require registration to download. If I link directly to the file, that would be bypassing their registration process. I worked with CIS folks in the past, they do awesome work, and for the value they provide to the community, a short registration, I believe is fair. I think you would like reading the hardening guidelines, some real good information there.

    Best Regards,

  4. Hi
    Can you please send how to hardning tomcat in production server and best practices.