0

I'm working with postgre (AWS RDS) for my db and using node (AWS EC2) for server side. I'm just starting out so I don't have much context. I always used other third party software like Parse for DB so I had my apps access db through Parse API. So I thought I would do the same for Postgres. The more I read about it the more people say I need a middle server to prevent a direct link from a client app to the DB for security reasons. I understand that point, hence the node server.

But then as I was using node libraries, I realized that a establishing a connection from the server to DB was heavy. Within the stable realm, I can only establish 20 connections at once. So if I had gone through a direct connection from client app to DB, it was going to be too intense for DB.

Other than the security reason, is this the main reason why people recommend using a middle server layer between client app and the DB?

Or are there other technical reasons I'm not aware of?

shle2821
  • 109
  • 1

3 Answers3

1

The reason an app must not connect directly to the database is simple: the app is code that you have released which runs in a place that you do not control, and thus cannot be trusted with database credentials.

Code can be reverse engineered, and the credentials discovered, and now the attacker has complete access to your database and can do anything the app had permission to do.

An intermediate layer creates and enforces a critical boundary: the entity talking to the database is can be trusted with access to the database since, barring design flaws, it will not willingly do anything to the database that it shouldn't, nor will it allow anyone else to ask it to.

All other considerations are essentially secondary, in the sense that even if you solve them, this one is still there, looming.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
0

The DB can be on any back-end server, including the web server or any other online services.

Since Parse doesn't support PostGres, you will have to find another system to manage your back-end, which may have a considerable impact on the front-end interactions as well.

What you shouldn't do is try to find a way for the front-end to connect directly to a database. Doing so causes a huge load on the DB and also implies important security issues.

Julie Pelletier
  • 1,010
  • 7
  • 8
0

Perhaps it is misunderstanding. Today Web application are NOT simple two tier setup. Even the good old XAMPP, WAMPP are Controller (Model-View-Controller).

User doesn't interact directly to your apps DB backend, they see the UI, the View layer. The backend workflow logic is your code, the Controller. While you connect to your DB model through your controller.

However, if you introduce some DB query functionality in the view , you must sanitize them. It doesn't matter how many "middle layer" you introduce.

Unless you need high-availability that let you transparently switch over your backend database server, OR load balance apps server, OR functionality queue services, OR server scale-out , etc. There is no reason to introduce unnecessary layer of middleware. Every middleware will introduce additional single point of failure.

You only introduce middleware only if you NEED them, not because somebody say you WANT them.

Example 1 of middleware : when you have complex Logic that need to communicate to different data source, using middleware with its rules logic that trigger the logic flow, is better than write the logic inside your application.

Example 2 of middleware : Use message queue system that pool and distribute task, message , information for stack of server for multi-processing or distributed processing. So if that particular apps is MQ aware, then you don't even need to connect to database, you just connect to the MQ server. Say after the completion, your apps send info to another queue to notify the results, and let another application take care of the logic.

Moving the Database Model far away from the apps controller logic sounds cool, but there is a sweet spot of balance. You need to aware your business requirement.

mootmoot
  • 304
  • 1
  • 6