This version of the documentation is archived and no longer supported.
  • Security >
  • Security Practices and Management

Security Practices and Management

As with all software running in a networked environment, administrators of MongoDB must consider security and risk exposures for a MongoDB deployment. There are no magic solutions for risk mitigation, and maintaining a secure MongoDB deployment is an ongoing process. This document takes a Defense in Depth approach to securing MongoDB deployments, and addresses a number of different methods for managing risk and reducing risk exposure

The intent of Defense In Depth approaches are to ensure there are no exploitable points of failure in your deployment that could allow an intruder or un-trusted party to access the data stored in the MongoDB database. The easiest and most effective way to reduce the risk of exploitation is to run MongoDB in a trusted environment, limit access, follow a system of least privilege, and follow best development and deployment practices. See the Strategies for Reducing Risk section for more information.

Strategies for Reducing Risk

The most effective way to reduce risk for MongoDB deployments is to run your entire MongoDB deployment, including all MongoDB components (i.e. mongod, mongos and application instances) in a trusted environment. Trusted environments use the following strategies to control access:

  • network filter (e.g. firewall) rules that block all connections from unknown systems to MongoDB components.
  • bind mongod and mongos instances to specific IP addresses to limit accessibility.
  • limit MongoDB programs to non-public local networks, and virtual private networks.

You may further reduce risk by:

  • requiring authentication for access to MongoDB instances.
  • requiring strong, complex, single purpose authentication credentials. This should be part of your internal security policy but is not currently configurable in MongoDB.
  • deploying a model of least privilege, where all users have only the amount of access they need to accomplish required tasks, and no more.
  • following the best application development and deployment practices, which includes: validating all inputs, managing sessions, and application-level access control.

Continue reading this document for more information on specific strategies and configurations to help reduce the risk exposure of your application.

Vulnerability Notification

MongoDB, Inc. takes the security of MongoDB and associated products very seriously. If you discover a vulnerability in MongoDB, or would like to know more about our vulnerability reporting and response process, see the Vulnerability Notification document.

Networking Risk Exposure

Interfaces and Port Numbers

The following list includes all default ports used by MongoDB:

By default, listens for connections on the following ports:

This is the default port mongod and mongos instances. You can change this port with port or --port.
This is the default port when running with --shardsvr runtime operation or shardsvr setting.
This is the default port when running with --configsvr runtime operation or configsvr setting.
This is the default port for the web status page. This is always accessible at a port that is 1000 greater than the port determined by port.

By default MongoDB programs (i.e. mongos and mongod) will bind to all available network interfaces (i.e. IP addresses) on a system. The next section outlines various runtime options that allow you to limit access to MongoDB programs.

Network Interface Limitation

You can limit the network exposure with the following configuration options:

  • the nohttpinterface setting for mongod and mongos instances.

    Disables the “home” status page, which would run on port 28017 by default. The status interface is read-only by default. You may also specify this option on the command line as mongod --nohttpinterface or mongos --nohttpinterface. Authentication does not control or affect access to this interface.


    Disable this option for production deployments. If do you leave this interface enabled, you should only allow trusted clients to access this port.

  • the port setting for mongod and mongos instances.

    Changes the main port on which the mongod or mongos instance listens for connections. Changing the port does not meaningfully reduce risk or limit exposure.

    You may also specify this option on the command line as mongod --port or mongos --port.

    Whatever port you attach mongod and mongos instances to, you should only allow trusted clients to connect to this port.

  • the rest setting for mongod.

    Enables a fully interactive administrative REST interface, which is disabled by default. The status interface, which is enabled by default, is read-only. This configuration makes that interface fully interactive. The REST interface does not support any authentication and you should always restrict access to this interface to only allow trusted clients to connect to this port.

    You may also enable this interface on the command line as mongod --rest.


    Disable this option for production deployments. If do you leave this interface enabled, you should only allow trusted clients to access this port.

  • the bind_ip setting for mongod and mongos instances.

    Limits the network interfaces on which MongoDB programs will listen for incoming connections. You can also specify a number of interfaces by passing bind_ip a comma separated list of IP addresses. You can use the mongod --bind_ip and mongos --bind_ip option on the command line at run time to limit the network accessibility of a MongoDB program.


    Make sure that your mongod and mongos instances are only accessible on trusted networks. If your system has more than one network interface, bind MongoDB programs to the private or internal network interface.


Firewalls allow administrators to filter and control access to a system by providing granular control over what network communications. For administrators of MongoDB, the following capabilities are important:

  • limiting incoming traffic on a specific port to specific systems.
  • limiting incoming traffic from untrusted hosts.

On Linux systems, the iptables interface provides access to the underlying netfilter firewall. On Windows systems netsh command line interface provides access to the underlying Windows Firewall. For additional information about firewall configuration consider the following documents:

For best results and to minimize overall exposure, ensure that only traffic from trusted sources can reach mongod and mongos instances and that the mongod and mongos instances can only connect to trusted outputs.

See also

For MongoDB deployments on Amazon’s web services, see the Amazon EC2 page, which addresses Amazon’s Security Groups and other EC2-specific security features.

Virtual Private Networks

Virtual private networks, or VPNs, make it possible to link two networks over an encrypted and limited-access trusted network. Typically MongoDB users who use VPNs use SSL rather than IPSEC VPNs for performance issues.

Depending on configuration and implementation VPNs provide for certificate validation and a choice of encryption protocols, which requires a rigorous level of authentication and identification of all clients. Furthermore, because VPNs provide a secure tunnel, using a VPN connection to control access to your MongoDB instance, you can prevent tampering and “man-in-the-middle” attacks.


Always run the mongod or mongos process as a unique user with the minimum required permissions and access. Never run a MongoDB program as a root or administrative users. The system users that run the MongoDB processes should have robust authentication credentials that prevent unauthorized or casual access.

To further limit the environment, you can run the mongod or mongos process in a chroot environment. Both user-based access restrictions and chroot configuration follow recommended conventions for administering all daemon processes on Unix-like systems.

You can disable anonymous access to the database by enabling authentication using the auth as detailed in the Authentication section.


MongoDB provides basic support for authentication with the auth setting. For multi-instance deployments (i.e. replica sets, and sharded clusters) use the keyFile setting, which implies auth, and allows intra-deployment authentication and operation. Be aware of the following behaviors of MongoDB’s authentication system:

  • Authentication is disabled by default.

  • MongoDB provisions access on a per-database level. Users either have read only access to a database or normal access to a database that permits full read and write access to the database. Normal access conveys the ability to add additional users to the database.

  • The system.users collection in each database stores all credentials. You can query the authorized users with the following operation:

  • The admin database is unique. Users with normal access to the admin database have read and write access to all databases. Users with read only access to the admin database have read only access to all databases, with the exception of the system.users collection, which is protected to prevent privilege escalation attacks.

    Additionally the admin database exposes several commands and functionality, such as listDatabases.

  • Once authenticated a normal user has full read and write access to a database.

  • If you have authenticated to a database as a normal, read and write, user; authenticating as a read-only user on the same database will invalidate the earlier authentication, leaving the current connection with read only access.

  • If you have authenticated to the admin database as normal, read and write, user; logging into a different database as a read only user will not invalidate the authentication to the admin database. In this situation, this client will be able to read and write data to this second database.

  • When setting up authentication for the first time you must either:

    1. add at least one user to the admin database before starting the mongod instance with auth.
    2. add the first user to the admin database when connected to the mongod instance from a localhost connection. [1]

New in version 2.0: Support for authentication with sharded clusters. Before 2.0 sharded clusters had to run with trusted applications and a trusted networking configuration.

Consider the Control Access to MongoDB Instances with Authentication document which outlines procedures for configuring and maintaining users and access with MongoDB’s authentication system.

[1]Because of SERVER-6591, you cannot add the first user to a sharded cluster using the localhost connection in 2.2. If you are running a 2.2 sharded cluster, and want to enable authentication, you must deploy the cluster and add the first user to the admin database before restarting the cluster to run with keyFile.


Simply limiting access to a mongod is not sufficient for totally controlling risk exposure. Consider the recommendations in the following section, for limiting exposure other interface-related risks.

JavaScript and the Security of the mongo Shell

Be aware of the following capabilities and behaviors of the mongo shell:

  • mongo will evaluate a .js file passed to the mongo --eval option. The mongo shell does not validate the input of JavaScript input to --eval.

  • mongo will evaluate a .mongorc.js file before starting. You can disable this behavior by passing the mongo --norc option.

    On Linux and Unix systems, mongo reads the .mongorc.js file from $HOME/.mongorc.js (i.e. ~/.mongorc.js), and Windows mongo.exe reads the .mongorc.js file from %HOME%.mongorc.js or %HOMEDRIVE%%HOMEPATH%.mongorc.js.

HTTP Status Interface

The HTTP status interface provides a web-based interface that includes a variety of operational data, logs, and status reports regarding the mongod or mongos instance. The HTTP interface is always available on the port numbered 1000 greater than the primary mongod port. By default this is 28017, but is indirectly set using the port option which allows you to configure the primary mongod port.

Without the rest setting, this interface is entirely read-only, and limited in scope; nevertheless, this interface may represent an exposure. To disable the HTTP interface, set the nohttpinterface run time option or the --nohttpinterface command line option.


The REST API to MongoDB provides additional information and write access on top of the HTTP Status interface. The REST interface is disabled by default, and is not recommended for production use.

While the REST API does not provide any support for insert, update, or remove operations, it does provide administrative access, and its accessibility represents a vulnerability in a secure environment.

If you must use the REST API, please control and limit access to the REST API. The REST API does not include any support for authentication, even if when running with auth enabled.

See the following documents for instructions on restricting access to the REST API interface:

Data Encryption

To support audit requirements, you may need to encrypt data stored in MongoDB. For best results you can encrypt this data in the application layer, by encrypting the content of fields that hold secure data.