Unleashing the Power of Secure Apache Tomcat
Securing Apache Tomcat starts with knowing what is actually exposed: the application connector, administrative applications, deployment credentials and the operating-system account running the service. A configuration copied from another server can miss those details, even when it appears to work.
This revised guide replaces earlier authentication and IP-restriction examples that did not implement the controls their descriptions claimed. Use documentation for your installed Tomcat branch before changing configuration.
Start with an inventory
Record the Tomcat and Java versions, listening ports, reverse proxy, deployed applications and service account. Identify who can change application files or deploy a new WAR. Remove example and administrative applications you do not use, and check the supported upgrade path for components you retain.
Keep administration separate from public traffic
The Manager application can deploy code. Treat its credentials and network access as administrative access, rather than another public login page. Restrict it to the people and management networks that need it. A public application does not require a publicly reachable Manager.
Test restrictions from both an allowed and a disallowed network. When a proxy sits in front of Tomcat, establish which client address the server sees before relying on an address-based rule.
Configure authentication at the right layer
Define application authentication, roles and URL constraints using the mechanisms supported by the application and Tomcat version. Do not assume that adding two authenticator Valves makes Tomcat require both password and client-certificate authentication.
Likewise, a web.xml security constraint is not an IP allowlist. Tomcat provides address-filtering Valves for that purpose, and network controls may also belong at the firewall or proxy. An empty authorisation constraint is not an instruction to allow everyone.
Review TLS from the user to the application
Document where TLS terminates and whether the next connection crosses an untrusted network. Use the connector syntax supported by the installed branch, an appropriate certificate and a planned renewal process. A self-signed laboratory certificate is not a substitute for a production trust configuration.
After a change, check redirects, secure cookies and application behaviour through the real public endpoint. Testing the connector alone may not exercise the proxy path.
Reduce what a compromised process can change
Run Tomcat under a dedicated service account with only the file access the application needs. Separate deployable code from writable uploads and temporary files. Keep credentials out of application packages and avoid granting the service account broad administrative privileges.
Make the next change verifiable
- Back up the relevant configuration and record the current service state.
- Test the change in a representative environment.
- Check successful logins and expected denials, not just whether the process starts.
- Review application and access logs without recording credentials or session tokens.
- Record the result and keep a tested rollback procedure.
A hardening checklist is useful when each item has evidence. “Access restricted” should mean a denied test request and a documented rule, rather than a setting someone remembers adding.
Official references
- Tomcat 10.1 documentation—select the documentation branch matching your installation.
- Valve configuration reference
- Tomcat 10 security advisories
Leave a Reply