Third-party security professional is recommending we run a reverse proxy in front of the web server (all hosted in the DMZ) as a best practice security measure.

I know this is a typical recommended architecture as it provides another level of security in front of a web application to prevent hackers.

However, as a reverse proxy is cheerfully shuttling HTTP back and forth between the user and the internal web server, it will not provide any measure of prevention of hacking on the web server itself. In other words, if your web app has a security hole, the proxy is not going to provide any meaningful amount of security.

And given that the risk of an attack on a web application is much much higher than that of an attack on the proxy, is there really much gained by adding an extra box in the middle? We would not be using any of the caching capabilities of a reverse proxy - just a dumb tool to shuttle packets back and forth.

Is there something else I'm missing here? Has reverse proxy HTTP packet inspection got so good it can detect meaningful attacks without major performance bottlenecks, or is this just another example of Security Theater?

Reverse proxy is MS ISA fwiw.

7 Answers 7


Apache has mod_security, which will detect common security attacks. There is also mod_cband, which can restrict bandwidth used. I wouldn't be surprised if ISA had something similar. Without something actually making checks on the HTTP traffic as it goes through the proxy, it's all a little pointless from a security point of view.

What a reverse proxy will give you is load balancing, fail-over, caching, SSL and filering off-loading, leaving your web servers to do what they're good at: serving HTML.


Will a reverse proxy in front of web server improve security?

A reverse proxy gives you a couple things that may make your server more secure.

  • A place to monitor and log what is going on separate from the web server
  • A place to filter or firewall separate from your web server if you know that some area of your system is vulnerable. Depending on the proxy you may be able to filter at the application level.
  • Another place to implement ACLs and rules if you cannot be expressive enough for some reason on your web server.
  • A separate network stack that will not be vulnerable in the same ways as your web server. This is particularly true if your proxy is from a different vendor.
    • Using Apache setup as a proxy in front of Apache server is probably not as helpful as something like Squid in front of Apache.

A reverse proxy with no filtering does not automatically protect you against everything, but if the system you need to protect is high-value then adding a reverse proxy may be worth the costs support and performance costs.


ISA Server is able to look for and prevent various HTTP exploits and prevent them from getting to the web server. While most modern HTTP servers are no longer exploitable by this, it does have the added benefit of not sending this traffic to the web server.

In addition ISA can make it easier to do things such as adding SSL acceleration and pre-authorization of users to various URLs. It can even act as a load balancer for you so you can easily add more web servers without using a separate hardware load balancer.

Be sure to take the pro's that this person is giving on ISA and weight it against how much added overhead it will cost to manage and run ISA compared to the benefits.


It could protect your application server from attacks based on bad HTTP requests... Especially if it's possible on the reverse proxy (and not on the application server) to configure exactly what a good request looks like and not allow bad requests through. If you have to tell it what bad requests look like, it'll almost certainly be useless. In other words, it might protect from buffer overflow attacks, but not from SQL injection.

Mostly, it sounds like security theater. You hired a security consultant, and they have to tell you something to do to improve your security. It's pretty unlikely an attacker will ever break into the reverse proxy and if they simply bypass it they can always blame you; so it's a safe recommendation.


Basically, reverse proxies will hide your infrastructure from the world. So it is mainly a case of security by obscurity, unless your web server is really unmanageable and unsecured.

It can also protect your webservers from some kind of DOS (distributed denial of service), especially if your website is "heavy", acting then as a caching layer.

It has also some gotchas with it: it will hide from your application the real IP of the customer. It will make you consume more server power, and add a layer of things that can break. Remember that your reverse proxy will have to handle more connections (usually two times more: connections to customers and connections to your web server).

At the end of the day, a reverse proxy won't spare you to have a secure website anyway.


One benefit that I don't think anyone else has talked about is the fact you don't have to open any external IP/ports through your external firewall. A good reverse proxy system will initiate the communication from inside your network to the server in the DMZ protecting the networks against direct attacks. This, however & as others have said, won't protect you against a poorly written application.


I think Zoredache has given a very good answer as to the benefits that a reverse proxy can provide. I have used Pound which is a reverse proxy, load-balancer, and HTTPS frontend.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .