I get the general principle of a DMZ i.e. place public facing servers in the DMZ to isolate and protect the corporate LAN. I have a web application which is to be public facing, this web app needs to communicate with a database server, so a pretty basic requirements.

Web App only requires to communicate over a specific port to the DB so all non essential ports would be closed. I am trying to protect the database as much as possible in case the web app is compromised.

My question regards the location of the database server should this be in the DMZ as well or does it have to be in the DMZ? My thinking is if the database is not in the DMZ and located on the corporate LAN at least one port is open to the database meaning a connection exists to the corporate lan and therefore defeating the benefit of a DMZ, so based on my logic the Database needs to be in the DMZ?

3 Answers 3


The purpose of the DMZ is to do not expose your DB directly to Internet. Instead you expose it to your web application, and your web application to Internet. But you need to take care of the security of both the web app and the DB.

If your web application gets compromised, it doesn't mean that the DB is as well. There are various vectors here, for example, you could have a SQL injection vulnerability in your code, so it would be irrelevant whether the DB is in a DMZ, private subnet or even the same host as the web application, because an attacker could retrieve info anyways.

Another example, somehow your application could lead to access the OS. But if your system is carefully hardened, the attacker could only access the resources the webapp user has access to. The database should not be any of those resources.

  • thanks for the comment; I am not really looking at this from an application level vulnerability such as the SQL injection you mention; but yes I understand about SQL injection, instead I am more interested in if the web server is compromised how the DB is protected as much as possible. if the DB and web server are the same DMZ an adversary can access the DB easier when the web server is compromised, so placing the DB also in a DMZ makes this more difficult.
    – Darragh
    Jul 18, 2016 at 19:55
  • @Darragh of course it may be easier to access the DB if the web server is compromised, because that means the attacker has access to a server in your network, so he can try to jump from that server to the DB. Then again, you need to carefully harden your server so that if the attacker is able to get into your server, he has the least limited privileges.
    – user15194
    Jul 19, 2016 at 7:57
  • thanks @ayozint I am going to have two DMZs one for each server and configure the firewall to only allow the web server communicate with the DB server on specific port from a specific IP source.
    – Darragh
    Jul 19, 2016 at 21:08
  • @Darragh I think still you don't understand what a DMZ is. Look up for the term in Google (or whatever search engine you use). There is no such thing like "two DMZs". DMZ is one, the public subnet where servers that are reachable from Internet are located.
    – user15194
    Jul 20, 2016 at 7:23
  • for example this is what I mean applicationarchitecture.files.wordpress.com/2010/03/…
    – Darragh
    Jul 20, 2016 at 20:51

Another way is to have a reverse proxy also known as load Balancer to act as traffic termination point to external and internal traffic. When traffic gets terminated at a proxy you can inspect the traffic headers and content before allowing it to be reestablished to your servers hiding behind the reverse proxy.

To combat web app attacks, you can consider a webApp firewall on top of your network firewall and intrusion detection and prevention systems.


If your application does not require write access to the database consider placing a read-only replica of the database in the DMZ then use an obscure port for the database replication with the "real" database.

You must log in to answer this question.

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