For a self-managed MongoDB, do four things: bind only to trusted interfaces, create a user administrator, enable access control, and use TLS. MongoDB binds to localhost by default, so exposure usually comes from a change someone made. Authentication then limits what a reachable server will let a client do.
Start with the network
The MongoDB documentation says mongod and mongos bind to localhost by default. If the machine has several interfaces, it advises binding to the private or internal one, and keeping instances reachable only from trusted networks. You can bind all IPv4 addresses with 0.0.0.0 or use net.bindIpAll, but that only makes sense behind firewall rules you have checked.
A typical config line lists the loopback address plus the private address your app servers reach:
net:
bindIp: 127.0.0.1,10.0.0.5
The address 10.0.0.5 is an example. Use your own.
Create the administrator, then enable access control
Order matters. The security checklist says to create a user administrator first, then other users. A common pattern on a fresh node is to start without authorization on localhost only, create the first user in the admin database, then turn authorization on and restart.
security:
authorization: enabled
MongoDB has a localhost exception that lets you create the first user from the local machine when none exist. Treat it as a bootstrap step, not a design, and confirm that connections without credentials are now rejected. Check this against the access control tutorial for your server version before you do it in production.
One user per person or application
The checklist calls for least privilege and a unique user for each person or application. Shared credentials make audit trails useless and rotation painful. The same page says to review database users and rotate credentials periodically, so put that on a calendar.
Encrypt traffic and logs
The checklist asks for TLS on all incoming and outgoing connections, including between mongod and mongos and from applications. It also recommends collecting logs in a central store, since they include authentication attempts and source IPs. For per user network limits, authenticationRestrictions in db.createUser() lets you pin an account to an address list.
Smaller items that add up
- Run MongoDB under a dedicated operating system account.
- If you do not use
mapReduce,$where,$accumulatoror$function, the checklist suggests disabling server side scripting with--noscripting. - Exclude data and log paths from antivirus scanning, which the page warns can quarantine files and corrupt the database.
- Track end of life dates and CVE announcements for your version.
For the role choices themselves, see MongoDB built-in roles and least privilege.
Quick check
Is MongoDB reachable from the network by default?
The documentation says mongod and mongos bind to localhost by default, so remote reachability comes from configuration changes.
Is a firewall enough without authentication?
No. The checklist treats access control, TLS and network limits as separate steps, and each covers a different failure.
Sources
- MongoDB manual: Security Checklist for Self-Managed Deployments
- MongoDB manual: Self-Managed Network and Configuration Security
Last reviewed: 19 October 2026.
