Grant least privilege roles in MongoDB

The fix

use admin
db.createUser({
  user: "app",
  pwd: passwordPrompt(),
  roles: [ { role: "readWrite", db: "appdb" } ]
})

One role, one database. That is what an application needs.

Why it matters

MongoDB’s built-in roles are convenient and several of them are far wider than their names suggest. The usual setup hands an application one of these:

Role	What it actually grants
root	Everything, on every database. Superuser.
readWriteAnyDatabase	Read and write every database, including other apps’
dbOwner	readWrite + dbAdmin + userAdmin on that database
readWrite	Read and write one database. This is the one you want.

dbOwner is the trap. It reads like “owns this database, scoped, fine” — and it includes userAdmin, meaning the account can create users and grant roles within that database. An injection against a dbOwner connection can mint itself a persistent credential. It is not a scoped version of readWrite; it’s a scoped version of admin.

root on an application account is worse and depressingly common, because it’s what the tutorial used to get things working.

Authentication is per-database

This trips people up more than the roles do.

Users belong to the database they were created in, which is their authentication database — and it has nothing to do with which database they can access. A user created in admin with readWrite on appdb authenticates against admin and works on appdb.

That’s why connection strings need authSource:

mongodb://app:secret@10.0.1.5:27017/appdb?authSource=admin

Without authSource=admin, the driver tries to authenticate against appdb, finds no user there, and fails with an authentication error that tells you nothing about the real cause. It is the single most common MongoDB connection problem, and it isn’t a permissions bug.

Create all users in admin and always set authSource=admin. One place to look, one thing to remember.

Custom roles when built-ins don’t fit

A reporting account that must never write:

use admin
db.createUser({
  user: "reporting",
  pwd: passwordPrompt(),
  roles: [ { role: "read", db: "appdb" } ]
})

And for genuinely narrow access, a custom role scoped to specific collections:

use admin
db.createRole({
  role: "appReadOrders",
  privileges: [{
    resource: { db: "appdb", collection: "orders" },
    actions: [ "find" ]
  }],
  roles: []
})

Collection-level scoping is worth reaching for when one credential shouldn’t see everything in the database — a reporting tool that needs orders but not users.

Verify it worked

List every user and role — the audit:

use admin
db.system.users.find({}, { user: 1, db: 1, roles: 1 }).pretty()

Find the dangerous ones:

db.system.users.find({
  "roles.role": { $in: ["root", "dbOwner", "readWriteAnyDatabase",
                        "userAdminAnyDatabase", "clusterAdmin"] }
}, { user: 1, roles: 1 })

Anything here that isn’t a named admin account is a finding. Applications should not appear.

Check what a specific user can do, resolved:

db.getUser("app", { showPrivileges: true })

Then prove the limit — connected as the app:

db.getSiblingDB("admin").system.users.find()
db.getSiblingDB("otherapp").someCollection.find()

Expect not authorized on both. If either returns data, the role is wider than you think.

Before you apply this

Narrowing a role breaks the application at its next operation, not at connect time — so it fails mid-request, and only on the code path that used the privilege you removed.

Find out what it actually does before you cut. Enable the profiler briefly on a staging copy:

db.setProfilingLevel(2)
// ...run the app...
db.system.profile.distinct("op")
db.system.profile.distinct("ns")

That shows which operations and which namespaces the account really touches — including the once-a-month job that creates an index and would fail under plain readWrite.

Don’t leave the profiler at level 2 on production: it records every operation, costs performance, and writes queries (possibly containing personal data) into a collection with different access rules than the data itself.

Two traps:

• You cannot change a user’s authentication database. A user in appdb and a user in admin with the same name are different accounts. Create the new one, migrate the connection string with authSource, verify, then drop the old one.
• Role changes don’t affect existing connections in all cases — a pooled connection may keep working until it recycles. Watch for a full pool cycle before concluding the change was clean, or you’ll get a surprise hours later.

Related

• Enable authorization — roles do nothing until this is on.
• Enable TLS — protects the credential these roles attach to.