Security
Authentication and Roles
Users, built-in roles, and least privilege for an application versus an operator.
MongoDB does not have to guess who you are. Authentication proves the client. Roles bound what that user may do. The application that serves Rahul's orders should not be the same database user that can dropDatabase or read every Atlas project.
| Who | Role shape |
|---|---|
| Node API | readWrite on the app database only — find, insert, update, delete |
| Reporting job | read on that database, not write |
| Human in Compass | read any, or a narrower custom role — not the app password |
| Cluster operator | Atlas Project Owner / dbAdmin — never baked into the API |
use app
db.createUser({
user: "orders-api",
pwd: passwordPrompt(),
roles: [{ role: "readWrite", db: "app" }]
})Built-in roles you will actually name in interviews: `read`, `readWrite`, `dbAdmin`, `userAdmin`, `clusterMonitor`. Atlas maps these to database users you attach to a cluster. SCRAM (username/password) is the default; TLS is assumed on mongodb+srv. LDAP / X.509 exist for enterprises — know they exist, do not configure them in this lesson. authSource=admin vs the app db is 'where the user document lives', not a second password.
Interview question
How should a Node.js app authenticate to MongoDB?
A dedicated database user with the least role that works — typically readWrite on the application database, not atlasAdmin or root. Credentials come from the environment or a secret manager. Humans use a different user. Built-in roles like read and readWrite are the usual interview names.