Why an exposed Tomcat AJP connector is a firewall bypass waiting to happen
Apache Tomcat has historically shipped with two ways in: the familiar HTTP connector, usually on port 8080, and the AJP connector, usually on port 8009. AJP is a binary protocol designed for communication between Tomcat and a trusted front-end, such as an Apache HTTP Server using mod_jk or mod_proxy_ajp, sitting in front of it. It was never designed to be exposed to untrusted clients directly.
The firewall-bypass pattern
A common, incomplete hardening step is to block the HTTP connector's port at the perimeter while leaving the AJP port reachable, on the assumption that a binary protocol most tools do not speak is effectively closed by obscurity. It is not. Any client that understands AJP, including a reverse proxy configured specifically to speak it, can be pointed at that port and will be treated as a trusted upstream, because the protocol itself carries no meaningful authentication by default. The result is that a control meant to stop direct access to the application is bypassed entirely through a second connector nobody firewalled.
What that trust buys an attacker
Because AJP assumes it is only ever spoken to by a trusted front-end, a Tomcat instance reachable over AJP will generally let that traffic reach deployed applications, management interfaces, or static resources the HTTP connector was specifically configured to restrict. The connector was never asked to make those trust decisions itself; it assumed the decision had already been made upstream.
Defences
The fix is not clever configuration on the connector; it is not exposing it at all. Bind the AJP connector to localhost or an internal interface when the front-end proxy runs on the same host, firewall port 8009 at the network boundary exactly as rigorously as the HTTP port, and disable the connector completely if nothing in the deployment actually uses it. Later Tomcat versions also added a required shared secret for AJP connections, which should be enabled wherever the connector must stay reachable across a network boundary.
The broader lesson
Any service with more than one listening connector needs every one of them accounted for in the threat model. Hardening the connector a security review happens to look at, while leaving a second one wide open, is not hardening the application at all.
Key takeaways
- Tomcat's AJP connector trusts its caller by design; it assumes a trusted proxy sits in front of it.
- Blocking the HTTP port while leaving AJP's port 8009 reachable does not actually close the server off.
- An exposed AJP connector can let traffic bypass restrictions the HTTP connector was configured to enforce.
- Bind AJP to a local or internal interface, firewall it as strictly as the HTTP port, or disable it if unused.
- Every listening connector on a service needs its own place in the threat model, not just the obvious one.
This note has been rewritten and checked for this edition; it is not a copy of the original post.