Is web application connected to a database via an application server more secure?

Question

I have heard from my colleagues and some other people on web suggest that it is more secure to run this configuration:

Web server -> Application server -> Database, than this:

Web server -> Database

The reasons that if an adversary takes control of a web server, then there is one more layer to overcome if you need the database.

I think that if an adversary controls the web server then they are as good as having full access to the database, since they will be able to execute arbitrary requests to the application server that will trust them. It will slow them down I guess, but the extra effort to implement a middle tier + all possible holes in the application introduced by that seems not to be worth the effort to me.

P.S. Since I was told that my question is to generic, I will add more information on the setup that I have.

I have a SPA client that talks only to the API and token is used as an authentication scheme. Web application really provides only the initial request to hook up the application and there are no other calls apart from static files and API. The web application then talks directly to the database in the Data Layer. I have just one user in the database and all access is controlled by the business logic and/or the authorization layer in my framework (e.g. roles in a token can be verified with attributes before it goes to business layer, so without a required role you are not allowed to access some API at all). So there is not danger in anyone calling any of the API (unless I fail in protecting them appropriately, but that's another story).

So taking into account this setup, would there be any advantage from security point of view to make web application's data layer to talk to the application server that will handle the business logic instead of the database directly (and the application server will talk to the database). In this case the web application is generally reduced to the initial loading of the client + a proxy to the application service, which seems quite superfluous to me.

Answer 1

"More secure" is unconstructive

Thinking something is "more secure" often leads to poor decision making. All sorts of things are more secure while being a bad idea. It's more useful to ask "Does this add meaningful security?" and "Is the security gained a reasonable tradeoff between cost and benefit?"

Tiers don't add much security

Most infosec books recommend the three-tier model. I've found the two-tier model is just as common (maybe more common) and this includes a large number of highly critical apps I've audited: online banking, etc.

The reality is that having two tiers is only a marginal security benefit over a single tier. People will often say "if the web server is hacked, they're not on the database". While technically true, that is misleading. The web server will have credentials to connect to the database, which will allow an attacker to extract all the data. You can imagine certain attack scenarios where having two tiers blocks particular exploit vectors, but these are uncommon.

The security benefit of three tiers vs two is even less than two vs one. And this is especially so with SPAs, where the web tier is on the client.

Edit To be clear, I mean tiers as in tiers on separate servers (virtual or physical) - rather than a purely logical separation.

Answer 2

If you distinguish between web server, application server and database then you actually mean front end, business logic and back end (storage). This is also called a multi-tier architecture with presentation tier, application tier and data tier. In this case the application server will not simply pass through any requests from the web server but only allow actions which fit the business logic. This means that all the security stuff (i.e. who can access what) is essentially done in the application server and the web server is just there to make this information accessible via a web browser.

If you instead only have web server and database then the business logic is essentially part of the web server. While this makes it often easier to start wih some web application the missing distinction between presentation and business logic will lead easily into a mess which nobody can understand anymore and which often allows to bypass the business logic and thus get direct access to the database for an attacker.

Note that the separation between the layers does not necessarily need to be done with a separate server or application, but it can also be an in-process seperation (i.e. API, classes...). But it is important that this separation can not be simply bypassed which can often be handled more securely with a separate process or server. A missing separation between presentation and application can sometimes be seen in that you can't access specific information by HTML but they are still accessible by a JSON or XML API.

Answer 3

You need an application layer as a filter because most* database systems do not allow permission handling which is fine-grained enough to handle multiple users.

Usually* you can create users with different read- and write permissions, but usually* these are designed for up to a few dozen users and do not scale well for thousands or even millions of users. Also, you usually* can only set permissions on a table-level not on a per-row level yet alone a per-field level.

This means it is hard for you to control what data your users can and can't view and which data they can and can't edit. To give an example, let's take a users-table with these columns

userId
password
profilePicture
createdDate
lastLoggedInDate

People should be allowed to change their own profilePicture, but not that of other people. Nobody should change the createdAt field and changing the userId could cause all kinds of hijinks. Every user must edit the lastLoggedInDate when they log in and set it to the current date, but not set it to anything different. Can your database handle this complexity*? Oh, and we haven't even talked about references between tables yet.

Well, but what if you simply forbid this on the client-layer by just not writing the GUI code to do the stuff the user is not supposed to do? The problem is that your database has no way to verify that your client application is really the program you wrote. When it speaks SQL and sends valid login credentials, the database will trust it. A malicious user could write their own client and send arbitrary SQL commands to your database.

_{* I don't want to say it is impossible for a database to exist which can do all that, but so far I haven't seen one. When you know one, feel free to comment.}