I'm looking to deploy infrastructure for a web application that will live on a LAMP stack. The infrastructure is such that this is the only application that will ever live on this server and it must be as secure as possible.

Traditionally, we deploy a front end server in a DMZ and have a DB server on a segregated network and between them is a firewall rule that only allows TCP 3306 calls from the web server back to the database server. When multiple applications live on a server, I see the relevance there as if one application/site gets compromised then the potential exists to quarantine the damages to the application & credentials that have been harvested.

With a single web application I'm struggling to see how this might provide a security benefit. In theory, if your web server gets compromised then people will have access to the DB credentials the application uses at which point it's game over, right?

From a strictly security perspective what are the major reasons to split the application into front and back end servers?

  • 1) Peppering 2) You don't need to give the web server the db's root password! Jun 30, 2016 at 17:24

3 Answers 3


In general, I agree with your implication that if you only have a single web application there is little security benefit to moving the DB onto a separate server. That being said, there could be some contrived scenarios where there might be a security benefit. For example, if the web application does not have full admin rights to the DB, then a compromised web server would reveal credentials for some access to the DB, but not all. If the DB resided on the same web server presumably the attacker might be able to gain full access to the DB too, rather than just the limited access for the found credentials. An example of partial DB rights might be giving the web application write access to a logging table but not read access.

  1. Performance and scalability is enhanced by deploying it on two servers.
  2. I can imagine someone making configuration errors and opening up more ports on the database server. Due to the presence of the firewall this will not lead to a vulnerability easily.

Separating these out may make your system much harder to attack.

For example, say there's a SQL injection flaw on your website. The attacker may be able to use SELECT INTO OUTFILE to write a shell to your system.


Because the database runs on the same server, this succeeds in writing the shell to the web root where the attacker can access it via the website and gain control of your server.

Of course, file system permission for the mysql process account and the web root should normally be set appropriately with the minimal required, but segregation of services onto different servers is a good defence in depth approach.

Additionally, not all attacks are the same. There could be one attack that gains root permission to your web server, but the attacker could only access the database tables that the website user has permissions to read from (again, defence-in-depth - ensure database permissions are set with the principle of least privilege as a goal). If the DB was on the same box, the attacker would have full control of all the data.

You must log in to answer this question.

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