MongoDB is a popular document-based NoSQL database. Here in this post, I am listing some mistakes that I’ve found developers make while working on MongoDB projects.
Database accessible from the Internet
Allowing your MongoDB database to be accessible from the Internet is the most common mistake I’ve found developers make in the wild. Mongodb’s default configuration used to expose the database to Internet; that is, you can connect to the database using the URL of the server it’s being run on. It makes perfect sense for starters who might be deploying a database on a different machine, given how it is the path of least resistance. But in the real world, it’s a bad default value that often is ignored.
A database (whether Mongo or any other) should be accessible only to your app. It should be hidden in a private local network that provides access to your app’s server only.
Although this vulnerability has been fixed in newer versions of MongoDB, make sure you change the config if you’re upgrading your database from a previous version, and that the new junior developer you hired didn’t expose the database that connects to the Internet with the application server. If it’s a requirement to have a database accessible from the open-Internet, pay special attention to securing the database. Having a whitelist of IP addresses that only have access to the database is almost always a good idea.
Not having multiple database users with access roles
Another possible security risk is having a single MongoDB database user doing all of the work. This usually happens when developers with little knowledge/experience/interest in databases handle the database management or setup. This happens when database management is treated as lesser work in smaller software shops (the kind I get hired for mostly). Well, it is not. A database is as important as the app itself. Your app is most likely mainly providing an interface to the database.
Having a single user to manage the database and using the same user in the application for accessing the database is almost never a good idea. Many times this exposes vulnerabilities that could’ve been avoided if the database user had limited access in the first place. NoSQL doesn’t mean “secure” by default. Security should be considered when setting the database up, and not left as something to be done “properly” after shipping.
Schema-less doesn’t mean thoughtless
When someone asked Ronny why he chose MongoDB for his new shiny app, his response was that “it’s schema-less, so it’s more flexible”. Schema-less can prove to be quite a useful feature, but with great power comes great responsibility. Often times, I have found teams struggling with apps because they didn’t think the structure for storing their data through when they started.
MongoDB doesn’t require you to have a schema, but it doesn’t mean you shouldn’t properly think about your data structure. Rushing in without putting much thought into how you’re going to structure your documents is a sure recipe for disaster. Your app might be small and simple and so easy right now, but simple apps become complicated very quickly. You owe your future self to have a proper well thought out database schema.
Most programming languages that provide an interface to MongoDB have libraries to impose some kind of database schema on MongoDB. Pick your favorite and use it religiously.
Premature Sharding
Sharding is an optimization, so doing it too soon is usually a bad idea. Many times a single replica set is enough to run a fast smooth MongoDB that meets all of your needs. Most of the time a bad schema and (bad) indexing are the performance bottlenecks many users try to solve with sharding. In such cases sharding might do more harm because you end up with poorly tuned shards that don’t perform well either. Sharding should be considered when a specific resource, like RAM or concurrency, becomes a performance bottleneck on some particular machine.
As a general rule, if your database fits on a single server, sharding provides little benefit anyway. Most MongoDB setups work successfully without ever needing sharding.
Replicas as backup
Replicas are not backup. You need to have a proper backup system in place for your database and not consider replicas as a backup mechanism. Consider what would happen if you deploy the wrong code that ruins the database. In this case, replicas will simply follow the master and have the same damage. There are a variety of ways that you can use to backup and restore your MongoDB, be it filesystem snapshots or mongodump or a third party service like MMS.
Having proper timely fire drills is also very important. You should be confident that the backups you’re making can actually be used in a real-life scenario. Practice restoring your backups before you actually need them and verify everything works as expected. A catastrophic failure in your production system should not be the first time when you try to restore from backups (often only to find out you’re backing up corrupt data).
About the author
Charanjit Singh is a freelance JavaScript (React/Express) developer. Being an avid fan of functional programming, he’s on his way to take on Haskell/Purescript as his main professional languages.
