The security of the JMX connection is dependent on the implementation provided by the JRE and therefore falls outside the control of Tomcat.

Typically, access control is very limited (either read-only to everything or read-write to everything). Tomcat exposes a large amount of internal information and control via JMX to aid debugging, monitoring and management. Given the limited access control available, JMX access should be treated as equivalent to local root/admin access and restricted accordingly.

The JMX access control provided by most (all?) JRE vendors does not log failed authentication attempts, nor does it provide an account lock-out feature after repeated failed authentications. This makes a brute force attack easy to mount and difficult to detect.

Given all of the above, care should be taken to ensure that, if used, the JMX interface is appropriately secured. Options you may wish to consider to secure the JMX interface include:

• configuring a strong password for all JMX users;
• binding the JMX listener only to an internal network;
• limiting network access to the JMX port to trusted clients; and
• providing an application specific health page for use by external monitoring systems.

Tomcat ships with a number of web applications that are enabled by default. Vulnerabilities have been discovered in these applications in the past. Applications that are not required should be removed so the system will not be at risk if another vulnerability is discovered.

The ROOT web application presents a very low security risk but it does include the version of Tomcat that is being used. The ROOT web application should normally be removed from a publicly accessible Tomcat instance, not for security reasons, but so that a more appropriate default page is shown to users.

The documentation web application presents a very low security risk but it does identify the version of Tomcat that is being used. It should normally be removed from a publicly accessible Tomcat instance.

The examples web application should always be removed from any security sensitive installation. While the examples web application does not contain any known vulnerabilities, it is known to contain features (particularly the cookie examples that display the contents of all received and allow new cookies to be set) that may be used by an attacker in conjunction with a vulnerability in another application deployed on the Tomcat instance to obtain additional information that would otherwise be unavailable.

The Manager application allows the remote deployment of web applications and is frequently targeted by attackers due to the widespread use of weak passwords and publicly accessible Tomcat instances with the Manager application enabled. The Manager application is not accessible by default as no users are configured with the necessary access. If the Manager application is enabled then guidance in the section Securing Management Applications section should be followed.

The Host Manager application allows the creation and management of virtual hosts - including the enabling of the Manager application for a virtual host. The Host Manager application is not accessible by default as no users are configured with the necessary access. If the Host Manager application is enabled then guidance in the section Securing Management Applications section should be followed.

When deploying a web application that provides management functions for the Tomcat instance, the following guidelines should be followed:

• Ensure that any users permitted to access the management application have strong passwords.
• Do not remove the use of the LockOutRealm which prevents brute force attacks against user passwords.
• Configure the RemoteAddrValve in the context.xml file for the management application which limits access to localhost by default. If remote access is required, limit it to specific IP addresses using this valve.

The default server.xml contains a large number of comments, including some example component definitions that are commented out. Removing these comments makes it considerably easier to read and comprehend server.xml.

If a component type is not listed, then there are no settings for that type that directly impact security.

Setting the port attribute to -1 disables the shutdown port.

If the shutdown port is not disabled, a strong password should be configured for shutdown.

The APR Lifecycle Listener is not stable if compiled on Solaris using gcc. If using the APR/native connector on Solaris, compile it with the Sun Studio compiler.

The JNI Library Loading Listener may be used to load native code. It should only be used to load trusted libraries.

The Security Lifecycle Listener should be enabled and configured as appropriate.

By default, an HTTP and an AJP connector are configured. Connectors that will not be used should be removed from server.xml.

The address attribute may be used to control which IP address the connector listens on for connections. By default, the connector listens on all configured IP addresses.

The allowTrace attribute may be used to enable TRACE requests which can be useful for debugging. Due to the way some browsers handle the response from a TRACE request (which exposes the browser to an XSS attack), support for TRACE requests is disabled by default.

The maxPostSize attribute controls the maximum size of a POST request that will be parsed for parameters. The parameters are cached for the duration of the request so this is limited to 2MB by default to reduce exposure to a DOS attack.

The maxSavePostSize attribute controls the saving of POST requests during FORM and CLIENT-CERT authentication. The parameters are cached for the duration of the authentication (which may be many minutes) so this is limited to 4KB by default to reduce exposure to a DOS attack.

The maxParameterCount attribute controls the maximum number of parameter and value pairs (GET plus POST) that can be parsed and stored in the request. Excessive parameters are ignored. If you want to reject such requests, configure a FailedRequestFilter.

The xpoweredBy attribute controls whether or not the X-Powered-By HTTP header is sent with each request. If sent, the value of the header contains the Servlet and JSP specification versions, the full Tomcat version (e.g. Apache Tomcat/9.0), the name of the JVM vendor and the version of the JVM. This header is disabled by default. This header can provide useful information to both legitimate clients and attackers.

The server attribute controls the value of the Server HTTP header. The default value of this header for Tomcat 4.1.x to 8.0.x is Apache-Coyote/1.1. From 8.5.x onwards this header is not set by default. This header can provide limited information to both legitimate clients and attackers.

The SSLEnabled, scheme and secure attributes may all be independently set. These are normally used when Tomcat is located behind a reverse proxy and the proxy is connecting to Tomcat via HTTP or HTTPS. They allow Tomcat to see the SSL attributes of the connections between the client and the proxy rather than the proxy and Tomcat. For example, the client may connect to the proxy over HTTPS but the proxy connects to Tomcat using HTTP. If it is necessary for Tomcat to be able to distinguish between secure and non-secure connections received by a proxy, the proxy must use separate connectors to pass secure and non-secure requests to Tomcat. If the proxy uses AJP then the SSL attributes of the client connection are passed via the AJP protocol and separate connectors are not needed.

The tomcatAuthentication and tomcatAuthorization attributes are used with the AJP connectors to determine if Tomcat should handle all authentication and authorisation or if authentication should be delegated to the reverse proxy (the authenticated user name is passed to Tomcat as part of the AJP protocol) with the option for Tomcat to still perform authorization.

The requiredSecret attribute in AJP connectors configures shared secret between Tomcat and reverse proxy in front of Tomcat. It is used to prevent unauthorized connections over AJP protocol.

The host element controls deployment. Automatic deployment allows for simpler management but also makes it easier for an attacker to deploy a malicious application. Automatic deployment is controlled by the autoDeploy and deployOnStartup attributes. If both are false, only Contexts defined in server.xml will be deployed and any changes will require a Tomcat restart.

In a hosted environment where web applications may not be trusted, set the deployXML attribute to false to ignore any context.xml packaged with the web application that may try to assign increased privileges to the web application. Note that if the security manager is enabled that the deployXML attribute will default to false.

This applies to Context elements in all places where they can be defined: server.xml file, default context.xml file, per-host context.xml.default file, web application context file in per-host configuration directory or inside the web application.

The crossContext attribute controls if a context is allowed to access the resources of another context. It is false by default and should only be changed for trusted web applications.

The privileged attribute controls if a context is allowed to use container provided servlets like the Manager servlet. It is false by default and should only be changed for trusted web applications.

The allowLinking attribute of a nested Resources element controls if a context is allowed to use linked files. If enabled and the context is undeployed, the links will be followed when deleting the context resources. Changing this setting from the default of false on case insensitive operating systems (this includes Windows) will disable a number of security measures and allow, among other things, direct access to the WEB-INF directory.

The sessionCookiePathUsesTrailingSlash can be used to work around a bug in a number of browsers (Internet Explorer, Safari and Edge) to prevent session cookies being exposed across applications when applications share a common path prefix. However, enabling this option can create problems for applications with Servlets mapped to /*. It should also be noted the RFC6265 section 8.5 makes it clear that different paths should not be considered sufficient to isolate cookies from other applications.

It is strongly recommended that an AccessLogValve is configured. The default Tomcat configuration includes an AccessLogValve. These are normally configured per host but may also be configured per engine or per context as required.

Any administrative application should be protected by a RemoteAddrValve (this Valve is also available as a Filter). The allow attribute should be used to limit access to a set of known trusted hosts.

The default ErrorReportValve includes the Tomcat version number in the response sent to clients. To avoid this, custom error handling can be configured within each web application. Alternatively, you can explicitly configure an ErrorReportValve and set its showServerInfo attribute to false. Alternatively, the version number can be changed by creating the file CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with content as follows:

server.info=Apache Tomcat/9.0.x

Modify the values as required. Note that this will also change the version number reported in some of the management tools and may make it harder to determine the real version installed. The CATALINA_HOME/bin/version.bat|sh script will still report the correct version number.

The default ErrorReportValve can display stack traces and/or JSP source code to clients when an error occurs. To avoid this, custom error handling can be configured within each web application. Alternatively, you can explicitly configure an ErrorReportValve and set its showReport attribute to false.

The RewriteValve uses regular expressions and poorly formed regex patterns may be vulnerable to "catastrophic backtracking" or "ReDoS". See Rewrite docs for more details.

The MemoryRealm is not intended for production use as any changes to tomcat-users.xml require a restart of Tomcat to take effect.

The JDBCRealm is not recommended for production use as it is single threaded for all authentication and authorization options. Use the DataSourceRealm instead.

The UserDatabaseRealm is not intended for large-scale installations. It is intended for small-scale, relatively static environments.

The JAASRealm is not widely used and therefore the code is not as mature as the other realms. Additional testing is recommended before using this realm.

By default, the realms do not implement any form of account lock-out. This means that brute force attacks can be successful. To prevent a brute force attack, the chosen realm should be wrapped in a LockOutRealm.

The manager component is used to generate session IDs.

The class used to generate random session IDs may be changed with the randomClass attribute.

The length of the session ID may be changed with the sessionIdLength attribute.

The cluster implementation is written on the basis that a secure, trusted network is used for all of the cluster related network traffic. It is not safe to run a cluster on a insecure, untrusted network.

If you are operating on an untrusted network or would prefer to exercise an over-abundance of caution, you can use the EncryptInterceptor to encrypt traffic between nodes.