MongoDB Security Review
Self-managed MongoDB has no access control until you switch it on, and one open network setting exposes everything. We test authentication, network exposure, and Atlas roles and access lists. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Atlas only accepts client connections from IP addresses on the project’s access list. Adding 0.0.0.0/0 is a valid entry and opens that list to the entire internet, leaving authentication as the only remaining barrier.
Why MongoDB and Atlas security comes down to access lists, roles and what the network exposes
MongoDB’s own configuration reference sets security.authorization to disabled by default, and is direct about what that means: a user can access any database and perform any action until it is switched on. Once role-based access control is enabled, MongoDB’s documentation on role-based access control notes that roles never limit privileges: if a user holds two roles, the one with the greater access always takes precedence, so a broad built-in role granted early can quietly outlive the narrower, user-defined role it was meant to replace.
Network exposure follows a similar pattern. MongoDB’s documentation on IP binding states that mongod and mongos bind to localhost by default, so a fresh install is not reachable from another machine until net.bindIp or net.bindIpAll is changed, usually to let an application server connect. Encryption in transit works the same way round: MongoDB’s TLS/SSL configuration guide requires net.tls.mode to be set to allowTLS, preferTLS or requireTLS before any connection is encrypted at all, so we test what a deployment’s bind address and TLS settings actually allow once it has been opened up for real traffic, not what a default installation ships with.
Atlas moves the same questions into the console rather than a config file. Its IP access list documentation confirms Atlas only allows client connections from entries on the project’s access list, and organisation and project roles sit above that again, since an Organization Owner inherits Project Owner access, including database access, to every project in the organisation whether or not they were ever added to it directly. The Data API and the wider Atlas App Services platform, including its HTTPS endpoints, GraphQL and Device Sync, reached end of life on 30 September 2025, so we confirm during scoping whether either is still deployed. For the wider family of cache and streaming platforms this scope splits from, see our NoSQL, cache and streaming security review, and our PostgreSQL security review for relational engines.
SCOPE
What we review in a MongoDB deployment
Authentication and Role-Based Access Control
security.authorization defaults to disabled, and MongoDB’s own documentation for that setting states plainly that with it disabled a user can access any database and perform any action, so authorisation has to be switched on deliberately rather than assumed. We test whether it is enabled on every instance in scope, and whether the roles granted once it is on are additive in the way MongoDB always applies them, so a broad role granted early does not quietly outlive a narrower one added later.
Application User Privilege and Custom Roles
MongoDB’s security checklist calls for a unique user for every person or application that connects, built from user-defined roles when the built-in roles grant more than that account needs. We test whether the account your application actually authenticates as holds only the privileges its own custom or built-in role says it should, rather than a role created once during setup and never revisited.
Network Exposure, bindIp and TLS
mongod and mongos bind to localhost by default, so a fresh instance is not reachable from another host until net.bindIp or net.bindIpAll is changed, and no connection is encrypted until net.tls.mode is set to allowTLS, preferTLS or requireTLS. We test what the deployment’s actual bind address, firewall rules and TLS configuration allow once it has been opened up to an application server or the wider network, not what a default installation ships with.
Atlas Organisation and Project Roles
An Atlas Organization Owner inherits Project Owner access, including database access, to every project in the organisation, whether or not they were ever added to that project directly, and Atlas documents this inheritance as intentional. We map every organisation and project role against who actually needs administrative reach, and flag an account that holds organisation-level access it only ever uses for one project.
Atlas Database Users, Authentication and Role Scope
Atlas database users authenticate by SCRAM password, X.509 certificate or federated identity, and each one is granted built-in or custom roles that Atlas can scope down to a single database or collection rather than the whole cluster. We test whether every database user’s role scope matches what that user or application actually needs, and whether a role built for one collection has been reused more widely because it was already there.
IP Access List and 0.0.0.0/0
Atlas only allows client connections to a cluster from entries on the project’s IP access list, and 0.0.0.0/0 is a valid entry on that list, opening the cluster to every address on the internet subject to authentication alone. We test what is actually in the access list against what the deployment needs to reach it, and whether a wide entry added for a migration or a one-off job was ever removed afterwards.
Private Endpoints and Network Peering
Atlas supports private connectivity through AWS PrivateLink, Azure Private Link or GCP Private Service Connect on M10 clusters and above, but enabling a private endpoint does not switch off an existing public IP access list entry or network peering connection, both of which keep working unless removed separately. We test which connection paths into a cluster are actually still open once private endpoints are in place, not just whether one has been configured.
Programmatic Access: API Keys, Service Accounts and the Data API
Atlas API keys and service accounts are scoped to an organisation or a project and control the Atlas Administration API, which manages clusters and configuration but does not provide access to the data stored inside them; the separate Data API and the wider Atlas App Services platform, including its HTTPS endpoints, GraphQL and Device Sync, reached end of life on 30 September 2025. We test what an API key or service account is actually scoped to do, and confirm during scoping whether any App Services surface is still deployed and reachable.
Backup Access and Database Auditing
Atlas separates who can create a snapshot from who can restore one and who can download or export it, and switching on database auditing needs Project Owner or Organization Owner access, with events such as user and role changes filterable once it is on. We test who actually holds each backup role against who needs it, and whether auditing is enabled and capturing the events that would show unauthorised access.
NoSQL Injection via Query Operators
MongoDB’s query language documents comparison operators such as $ne, $gt and $in for filtering data by value, so an endpoint that passes a request body straight into a query filter can be handed an operator object instead of the plain value it expects. We test the application’s own query-building code for unsanitised input reaching these operators, not the database engine itself.
OUR PROCESS
MongoDB and Atlas Security Review: From Scope to Attestation
Scope and Access
We agree which MongoDB instances, Atlas projects and clusters are in scope, plus a database user for every privilege tier you want tested and, where relevant, an Atlas project or organisation role to review configuration.
Role and Access Mapping
We map every role, database user and access list entry against who or what actually needs that level of access, on self-managed instances and in Atlas.
Manual Testing
A CREST-certified tester manually tests authentication and authorisation, network exposure and TLS configuration, Atlas access lists and private endpoints, and API key or service account scope, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST MongoDB pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent MongoDB and Atlas Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test MongoDB For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From MongoDB and Atlas Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our MongoDB deployment?
We need at least one authenticated database user for every privilege tier in scope, from an ordinary application user through to a role that can query user and role configuration on a self-managed instance, or the equivalent project role in Atlas. Read access to the Atlas project’s organisation and project role assignments speeds up the review, though we can test with database-level access alone.
Will testing touch live data?
We test the databases, collections and clusters you nominate, working against your actual roles, access lists and application queries rather than a copy, so we agree exclusions such as destructive commands, bulk deletes or production replica targets before testing starts. We do not export real customer data or run destructive tests without that agreement in writing.
Do you test self-managed MongoDB and Atlas the same way?
The underlying questions are the same: who can authenticate, what role they hold, and what the network actually exposes. What differs is the boundary, since Atlas manages the host, the storage engine and features such as backups and private endpoints, so we confirm during scoping exactly what you control on your Atlas tier and test to that boundary.
What is out of scope for a single-system MongoDB review?
We never test MongoDB’s own source code, the underlying host or hypervisor of a managed Atlas cluster, or Atlas’s shared infrastructure, and a separately hosted application that happens to connect to the database is scoped and quoted on its own. We test the authentication, roles, network configuration, access lists and application-level query handling for the instance or cluster you nominate.
Does MongoDB or Atlas have a policy on customer penetration testing?
MongoDB publishes security and shared-responsibility documentation for Atlas, but we have not found a published rules-of-engagement page for customers testing their own Atlas projects in the way AWS, Microsoft Azure and Google Cloud publish for their platforms. We confirm MongoDB’s current terms for testing your own Atlas project during scoping and test within them.
Is the Data API or Atlas App Services in scope?
The Data API and the wider Atlas App Services platform, including HTTPS endpoints, GraphQL and Device Sync, reached end of life on 30 September 2025, so most Atlas projects no longer expose them. If your project still has App Services configured, we scope it in during the call rather than assuming it matches the current platform.
How long does a MongoDB security review take?
A single MongoDB instance or Atlas cluster, with a small number of databases and a limited set of roles, sits in our 2-day single-system scope, with a report typically landing around 5 working days after kickoff. More databases, multiple Atlas projects, or a mix of self-managed and Atlas deployments moves into a larger scope with more testing days.
Are your testers CREST certified?
Yes. Every MongoDB engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your MongoDB review
Self-managed MongoDB has no access control until you switch it on, and one open network setting exposes everything. We test authentication, network exposure, and Atlas roles and access lists. CREST-certified testers, fixed price from £2,620 for a 2-day single-system scope, quoted within 24 hours.
