Secure Your MongoDB Installation

DZone 's Guide to

Secure Your MongoDB Installation

It is never a good strategy to leave a database completely unauthenticated. It turns out that enabling a really basic authentication in MongoDB is quite simple.

· Database Zone ·
Free Resource

There have been plenty of stories about MongoDB data leaks because people found lots of MongoDB data exposed on the Internet without any protection.

The root of the problem is probably a bad default setting MongoDB has that actually starts without any authentication by default. Developers often download MongoDB, configure without authentication, and access their MongoDB instance without any knowledge of MongoDB's security model. This simplicity of usage can lead to an unsecured installation in production.

While this can be tolerable for a MongoDB instance on an intranet, it is never a good strategy to leave MongoDB completely unauthenticated. It turns out that enabling a really basic authentication is quite simple, even in the community edition.

Once you've started your MongoDB instance without authentication, just connect to it with your tool of choice (like Robomongo) and create a user admin in the admin database.

use admin
 user: "admin",
 pwd: "mybeautifulpassword",
 roles: [ { role: "root", db: "admin" } ]

Once this user is created, just stop MongoDB and change this configuration to enable authentication:

 authorization: enabled

If authorization is enabled in the configuration file, MongoDB will require that all of your connections to the server be authenticated. There is a nice tutorial on the MongoDB site, but basically once authorization is enabled you can authenticate on a single database or to the admin database. With the above instructions, I’ve created a user admin on the admin database with the role root. This is the minimum level of authentication you should have, with a single user that can do anything. 

This configuration is far from being really secure, but at least it avoids access to the MongoDB instance without a password. It is equivalent to enable only the user “sa” on a SQL Server.

The next step is changing your connection string inside your software to specify user and password. The format of the URL is this:


Much like native authentication in SQL Server, username and password are stored in a connection string, and pay attention to the authSource parameter of the connection string. If you omit that parameter, the C# driver may try to authenticate against the specified database (newDb in this example) and fail because the only user is in the admin database. Thanks to the authSource parameter you are able to specify the database to use to authenticate.

You don’t need to change anything else in your code because the connection string contains all the information to authenticate the connection.

To avoid having an unsecured instance of MongoDB in production, start immediately securing your database directly during developing phase, so every person included in the process knows that they will need a password to access the database.

admin, authentication, database, mongodb, security, sql, sql server

Published at DZone with permission of Ricci Gian Maria , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}