Security Benefits of Reverse Proxying Java / Tomcat WebApps Locally

Question

Conventional wisdom seems to dictate that java applications should always be reverse proxied. It's what I have always done and so has everywhere I have worked at.

I have read multiple times that reverse proxying is recommended without much substantiation. Typically moreso with tomcat and apache.

I understand some of the advantages generally with reverse proxying; you are moving some of the request validation and filtering north of the application but I was wondering if there was a more in depth explanation to this, specific to Java?

I've googled this a bit and not come up with anything detailed or compelling.

I assume that tomcat receives the HTTP request rather than passing it direct to the application.

To clarify: Reading the answer below, Im not asking why proxies are commonly used or how to configure them but the security benefits they would provide when running on the same server as the application (excluding segmentation etc..).

Answer 1

Focusing solely on the (claimed) security benefits. There are multiple elements to this. I'll address each in turn.

Robustness against attacks that utilise malformed requests. The thinking here is that the reverse proxy does a better job of rejecting malformed requests and therefore does a better job of defending against attacks that depend on the server incorrectly handling the invalid request. In my opinion (as a Tomcat committer) I do not support this view in the case of Tomcat. Where it could apply is if you are using something (doesn't have to be Java based) that isn't intended to be internet facing to host your service. Then fronting with a reverse proxy makes sense.

Simpler TLS configuration. Certainly true historically when certificate authorities tended to provide certifications only in PEM form the conversion process to a Java KeyStore was not well documented. There have been improvements across the board on this. Certificate authorities are providing Java KeyStore specific instructions, Java itself is moving away from KeyStores to PKCS12 and Tomcat can use certificates in PEM format (the same format httpd uses). In my view this point doesn't carry much weight these days.

The reverse proxy offers more configuration options. This is generally true. If you need to block a header, integrate with an external authentication and authorisation system, modify a response then while you can do all of the above with Tomcat, you will need to write some code to do some of these things in Tomcat that you can do with configuration in the reverse proxy. How important this is to you will depend on what it is you are trying to achieve. One benefit I have seen is that when a new vulnerability emerges, you can often configure the reverse proxy to block the attack (e.g. with modrewrite) more easily than Tomcat.

The counter argument is that by adding a reverse proxy you are increasing the attack surface. Now you need to worry about vulnerabilities in the reverse proxy as well as your Java component.

You also need to ensure that the reverse proxy is configured correctly - especially if the reverse proxy is terminating https and then using http to the back-end. You need to be very careful to ensure that the back-end knows which requests were received (by the reverse proxy) over https and which over http otherwise you'll open yourself up to a bunch of potential vulnerabilities such as leaking secure session IDs over http.

Generally, it is probably more important to stick to what you know. If you are an experienced httpd administrator who is happy setting up httpd instances securely then you are more likely to end up with a secure configuration if you proxy through httpd rather than try and configure something you don't know. Likewise, an experienced Tomcat administrator is likely to end up with a better result with just Tomcat rather than adding an unfamiliar reverse proxy.

Overall, I suspect that the non-security arguments for using a reverse proxy (load-balancing, exposing multiple services through a single hostname) are likely to drive the decision whether or not to use one.

Answer 2

First of all I would like to give you a brief understanding of a reverse proxy: A reverse proxy can be used outside the firewall to represent a secure content server to outside clients, preventing direct, unmonitored access to your server’s data from outside your company.It can also be used for replication; that is, multiple proxies can be attached in front of a heavily used server for load balancing. But how does a reverse proxy work? You can use two different methods for reverse Proxying. One method takes advantage of Proxy Server’s security features to handle transactions. The other method uses caching to provide load balancing on a heavily used server. Both of these methods differ from the conventional proxy usage because they do not operate strictly on a firewall. Assume that i have an HTTP proxy in the form of a Java Servlet, An HTTP proxy is useful for AJAX applications to communicate with web accessible services on hosts other than where the web application is hosted.I can implement an HTTP proxy into a java Servlet. There is a good example of a more in depth explanation to your question in this link: https://www.nginx.com/resources/wiki/start/topics/examples/javaservers/ In the link NGINX works as a reverse proxy in the front of Java Servers.