Let's say I have a straight forward completely database driven web site application and I store my database on my web server in the DMZ. I won't be broadcasting the IP address of my database because I won't be sending calls to it, which makes my database inaccessible to the outside world.

If I place my database on the internal network, and then place a web service hosting my data access layer on a separate application server in an internal sub network between the outward facing web site application server sitting in the DMZ and the database server in the LAN, isn't that simply broadcasting the location of my database, icluding the user login information?

Isn't the second method simply telling everyone in the outside world where my database is located?

  • 1
    The second method is something you should try to avoid / should not want. Hosting the database server in your trusted zone and making it accessible from the DMZ is a bad practise as you should never allow traffic from the DMZ to go to the trusted zone. In order to answer your question, I don't think it is considered "broadcasting" the outside world where your database is located since your front-end server(s) should only communicate with the database server.
    – Jeroen
    May 7, 2015 at 4:58

3 Answers 3


It's a bad idea to host a database server on your internet facing webserver.

If the underlying OS of your web/DB server, or webserver platform itself contains any vulnerabilities that can be exploited then your database will be compromised.

I won't be broadcasting the IP address of my database because I won't be sending calls to it, which makes my database inaccessible to the outside world.

This is not true. If your web application is vulnerable to SQL Injection it doesn't matter where your DB resides on the network, it will be directly accessible and exploitable from a client on the internet.

Ideally your application would be designed around an N-Tiered Architecture with each tier residing in a different DMZ. Preferably each tier would also contain network monitoring equipment to enforce protections and alert on suspicious activity. (WAF, IPS/IDS, Database Activity Monitoring, etc)

3 Tier Architecture

Image from: http://en.wikipedia.org/wiki/Multitier_architecture


Think of the scenarios of compromise. If you host the database on the same system as the web service, then a compromise of the web service results in immediate compromise of the database. So, this is minimally secure.

If you host the database on an "internal" server that the web service can access (via an internally facing network interface or special firewall rules) then an attacker who compromises the web service does not immediately have access to the database, but they will quickly find the credentials used by the web service for the database, and proceed to access it at will.

Is the second scenario meaningfully more secure than the first scenario? It depends on how the database is used. You can put design and security measures in place to limit what the web server can get from the database, depending on what your application is doing. Otherwise, you are better off just doubling down on the web server to protect it with every means available.

  • +1 for noting that HOW you use the database is what matters, not blindly following a design pattern. May 7, 2015 at 16:05

I won't be broadcasting the IP address of my database because I won't be sending calls to it, which makes my database inaccessible to the outside world

Not knowing an IP address does not make something in that address inaccessible. In an analogy it is a house without a street address. If a thieve walks by that house, he can still enter the door. In order for your database to be inaccessible you need to use a firewall. For example, you can prohibit access to your database port from the external network.

I think you do not understand the term DMZ to its full extent. DMZ can be implemented in many ways, and its purpose is to put security measures between the external facing network and the rest of the internal network which should not have anything externally facing. This means that even if a breach occurred on a certain server in the DMZ, utilizing it to get access to other machines in the internal network will be much harder.

Even if you have the IP address of a machine in the internal network, that will not grant you access from the external network to that machine, thanks to the firewall which protects the internal network from the outside world.

Having said that, your internal IP addresses and of course the credentials used to authenticate with other services in the internal network are still sensitive data which should be kept secret. This is an "extra" security measure on top of your firewall, in case someone got access into your internal network, for example by infecting one of the devices in your internal network with a virus.

Keeping these as a secret is done with the right configuration of the web server, not to expose these details to the outside world, and it is also recommended to encrypt these details as an additional security measure.

You must log in to answer this question.

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