Keep the database off the public internet
Place database services on private networks and allow connections only from required application, administration, monitoring, and backup systems. Bind self-managed instances to the intended interfaces, use host firewalls or security groups, and avoid broad address ranges. Administrative access should pass through controlled channels with individual identities and auditable authentication.
Enable authentication before loading production data. Create a unique database user for each application and operational function. Grant the smallest set of database, collection, and administrative actions required. Do not run an application with cluster-administrator credentials.
MongoDB’s official security checklist recommends access control, role-based permissions, TLS, network restriction, encryption, auditing, dedicated operating-system users, secure configuration, and regular updates.
Protect data in transit, at rest, and in backups
Require TLS for client, administrative, and cluster communication and validate certificates. Encrypt storage volumes or use supported database encryption, then manage keys separately from the data. For particularly sensitive fields, evaluate client-side or queryable encryption in the context of search, key lifecycle, recovery, and operational complexity.
Backups contain the same sensitive information as the live database. Encrypt them, separate backup privileges from normal application access, restrict retention, and monitor retrieval. Regularly restore into an isolated environment and verify both technical consistency and the application’s ability to use the recovered data.
Prevent injection and excessive access in application code
Validate request data before using it in queries. Do not allow clients to supply arbitrary MongoDB operators, aggregation stages, field names, projection rules, or JavaScript expressions. Build queries from fixed application structures and allowlisted choices. Prevent unsafe object merging and reject property names that could affect prototypes or query semantics.
Authorization belongs in the application as well as the database. A valid query still needs to be scoped to the current user, tenant, or permitted organization. Apply field-level response rules so sensitive attributes are not returned merely because they exist in a document.
Disable server-side scripting when the deployment does not require it. Review use of $where, $function, $accumulator, and map-reduce features because they change the execution and review surface. Bound query time, result size, aggregation complexity, and pagination to protect availability.
Harden self-managed operations
Run database processes under dedicated operating-system accounts and protect configuration, key, log, and data files with restrictive permissions. Keep MongoDB and the host operating system on supported versions and monitor product advisories. Separate development, testing, and production databases and credentials.
Avoid placing passwords directly in shell history, process arguments, source code, or tickets. Use a secret manager or protected runtime configuration and rotate credentials. When a managed database is used, review network access lists, private connectivity, database users, project roles, API keys, federation, alerts, and organization-level controls rather than assuming the provider secures application access automatically.
Audit and monitor meaningful activity
Centralize authentication, connection, administrative, and relevant data-access logs. Alert on failed login patterns, new users or roles, permission changes, unexpected public connectivity, large exports, unusual queries, disabled auditing, and backup failures. Logs and audit records need access restrictions and retention rules of their own.
Maintain an inventory of databases, clusters, owners, applications, classifications, backups, and end-of-life dates. Incident procedures should include credential rotation, network containment, evidence preservation, scope analysis, recovery, and notification assessment.
MongoDB and database review checklist
- Database endpoints are private and limited to known systems and administrators.
- Authentication is mandatory and every workload has a least-privilege identity.
- TLS, storage encryption, key controls, and protected backups are in place.
- Query operators, projections, aggregations, and result sizes are application-controlled.
- Application authorization scopes every query to the correct user or tenant.
- Versions, configuration, users, roles, and network rules are reviewed regularly.
- Auditing, alerts, backup restoration, and incident procedures are tested.
