Don't connect your App to your database

In web development, connecting the application to a database is rarely an issue. Most programming languages come with a database driver that does all the work. You call the connect function with credentials and host as arguments, and you are in. When working on a phone app, we expect to do the same thing. But there is a key difference here.

In the first case, the credentials live in the web server. A hopefully secure server that the we have control over. But in the phone app, the credentials live in the app. This means, the end-user's phone connects directly into our database server. Not only this is a security risk, it also becomes a pain to update the app.

I've been speaking to a group of students building their first app for a school project. I had to explain why it wasn't a good idea to connect to the database directly. I also hope to answer the question here, so anyone with the same issue can find an answer.

Why it is not a good idea.

As I mentioned above, in web development the application lives in the web server. It's easy enough to follow best practice to secure your web server. We can use a SSH key to log into the machine, disable the root account, and create robust firewall rules. If there are any signs of being compromised, we can reset all accounts, patch the OS, and change passwords. It's even possible to limit which IP address is allowed to access the machine.

In other words, we have control over the machine and what is allowed to run on it.

When the application lives on the user's device, some control is ceded to the device. Especially if it can connect to the database. This means the application needs credentials to connect to our database. The web application only needs one connection to access our data. But every person that downloads the app connects directly into our database.

If the app grows in popularity, there is no easy way to scale it. If a few hundred people use the application at once, the database will fail. The only way to survive would be to get a bigger server and increase the number of allowed connections. But eventually, the number of users will overwhelm the database.

If we make a single schema change to our database, the app will instantly fail for all users. The user will have to update the app to get the latest working version.

Also, unless the web server is compromised, there is no way for someone to extract the database credentials. But an app that lives on a user's device can be reverse engineered. The clever hacker can extract those credentials from the app. Nothing stops him from querying our database like it was his own.

What's the solution?

Use API Endpoints. The only reason the application connects to the database is to retrieve data. Rather then using queries to retrieve this data, it's better to request it using an API. This means, we have to build a web app that can fetch and return data securely.

So instead of writing something like this:

SELECT name FROM recipe WHERE id = 123

We instead make a call to get the data like this:

https://api.example.com/v1/recipe/123

The difference here is that the application is not concerned with how that data is generated. It makes a web request and receives the data. We can change columns or even change our database from MySQL to MongoDB. As long as the data returned is in the same format, the application will continue to work.

This also removes the incentives to reverse engineer the app. Since no database credentials are passed around, a hacker can't query our database.

We can scale our web application if it gets popular. We can use a caching mechanism, re-engineer it entirely without affecting our users. We can even support users that haven't updated the application in a while.

---

When the app connects the database directly, we introduce three main issues:

• We can't make changes to our database because the app on the user's phone depends on specific table structures.
• We can't scale our app because all users connect to a single database.
• We allow hackers to reverse engineer our app and steal our database credentials.

Using an API Endpoint helps mitigate all these issues. It does require more work upfront since we need to build a web app besides our smartphone app. But it will pay dividends in the long run making our app more secure and easier to scale.

---