Editor’s note: This post is the third in a four-part series exploring how MongoDB Atlas Resource Policies help you strengthen database security and enforce consistent guardrails across your organization. Read the first post on IP access list management here and the second on defense in depth strategies here. The final post in this series will cover enforcing cloud hyperscaler and region restrictions across your organization.
The “just temporarily” lie that destroys security
It’s 2 a.m. Your production application is down. The database won’t accept connections. Pressure is mounting. Every minute of downtime costs thousands of dollars. A developer makes a split-second decision: add 0.0.0.0/0 to the IP access list. “Just temporarily,” they promise. “We’ll fix it properly tomorrow.”
Tomorrow never comes.
Six months later, that “temporary” wildcard is still there. Your database has been accessible to the entire internet this entire time. Every brute-force attack, every credential stuffing attempt, every automated bot scanning for exposed databases—they’ve all had unrestricted access to try breaking in. You discover this during a security audit, and the implications make your stomach drop.
This scenario plays out hundreds of times across organizations of every size. The wildcard IP address 0.0.0.0/0 represents the single most dangerous configuration in database security, yet it appears constantly because it’s the path of least resistance when teams are under pressure.
What if that path simply didn’t exist? That’s exactly what MongoDB Atlas Resource Policies enable. They turn security best practices into enforceable guardrails that no one can bypass.
The wildcard: 0.0.0.0/0
Before we explore solutions, let’s understand exactly what 0.0.0.0/0 means and why it’s so catastrophic.
In network security, 0.0.0.0/0 is a Classless Inter-Domain Routing (CIDR) notation—a shorthand way of specifying ranges of IP addresses—that means “every possible IP address on the internet.” When you add this to your MongoDB Atlas IP access list, you’re telling the database, “Accept connection attempts from literally anywhere.” It’s the digital equivalent of leaving your front door wide open with a sign saying “Come on in!”
So why do developers use this wildcard IP?
It isn’t added maliciously. Developers use it because it solves immediate problems. When you’re trying to connect to a database and getting rejected, adding 0.0.0.0/0 eliminates all network-level barriers instantly. There is no need to determine which specific IP addresses should be allowed. No need to coordinate with networking teams to get CIDR blocks. No need to wait for VPN configurations. It just works.
This convenience makes the wildcard IP seductive during several common scenarios. Development teams working from home with dynamic IP addresses find it easier than constantly updating the access list. DevOps engineers use it to troubleshoot connection issues by eliminating network configuration as a variable. Third-party contractors require temporary access without having to go through formal access request processes. Proof of concept (POC) projects that “won’t go to production” often get deployed with wildcard access still enabled.
The problem isn’t that developers are careless. It’s that the system makes the dangerous choice the easiest choice.
The hidden costs of wildcard access
The true danger of 0.0.0.0/0 extends far beyond the obvious security implications.
Attack surface expansion
Every MongoDB Atlas cluster with wildcard access becomes visible to every automated scanner on the internet. These aren’t sophisticated targeted attacks; they’re opportunistic bots that probe millions of IP addresses looking for exposed databases. They attempt default credentials, known vulnerabilities, and brute-force attacks around the clock. Your logs are filled with thousands of failed connection attempts from IP addresses in countries you’ve never operated in.
Compliance violations
Security frameworks like SOC 2, ISO 27001, PCI DSS, and HIPAA all require documented network access controls. Wildcard IP access fundamentally violates these requirements. During audits, explaining why your production database accepts connections from anywhere becomes a conversation-ending finding. Remediation requires extensive documentation, incident reports, and proof that no unauthorized access occurred—assuming you can prove that at all.
Forensic nightmares
When a security incident occurs, investigators need to determine what happened and who had access. With wildcard access, that question becomes unanswerable. Legitimate users and potential attackers all connect through the same wide-open door. Logs show connections from various IP addresses, but it cannot be definitively determined which were authorized. This ambiguity extends incident response timelines and makes it nearly impossible to assess the true scope of breaches.
Architectural debt
Organizations that rely on wildcard access often fail to develop a proper network architecture. Teams often lack knowledge of VPC peering, private endpoints, and bastion hosts. They don’t implement proper IP allow lists or VPN-based access. This architectural debt compounds over time, making it harder to implement real security controls later because “everything works now” and nobody wants to be the one who breaks it.
The blast radius of breaches
The most sobering reality is how much worse breaches become with wildcard access. If attackers compromise credentials through phishing or leaked secrets, wildcard access enables them to connect from anywhere, including their own infrastructure, compromised cloud instances, or residential IP addresses. Without network-level restrictions, stolen credentials become a master key that can be used from any location globally.
MongoDB Atlas Resource Policies: Making wildcard access impossible
MongoDB Atlas Resource Policies solve the wildcard problem by making it technically impossible to add 0.0.0.0/0 to any IP access list in your organization. This isn’t documentation, training, or best practices that humans might forget or ignore. It’s automated enforcement that applies consistently across every project, every cluster, and every team member.
The policy
MongoDB Atlas Resource Policies are defined using the open-source Cedar policy language. Here’s the complete Cedar policy that blocks wildcard IP addresses:
How it works
This policy operates at the organization level and automatically applies to all projects within your organization. When anyone attempts to modify an IP access list—whether through the MongoDB Atlas UI, the Atlas CLI, the Atlas Administration API, or Terraform—the system evaluates this policy before allowing the change to take effect.
If the modification would result in 0.0.0.0/0 being present in the IP access list, MongoDB Atlas blocks the action immediately and returns a clear error message explaining why the change was rejected. The developer receives instant feedback about what they can’t do and why, teaching the rules through experience rather than requiring them to read documentation first.
The policy’s scope is comprehensive. It prevents adding 0.0.0.0/0 to new clusters, modifying existing clusters to add the wildcard, and making any API calls or infrastructure-as-code changes that would introduce wildcard access. There are no backdoors, exceptions, or ways to circumvent the policy without Organization Owner privileges to modify the policy itself.
What happens to existing wildcards
A common question is: What happens to clusters that already have 0.0.0.0/0 in their access lists when this policy is deployed? MongoDB Atlas handles this gracefully. Existing connections continue working, and clusters remain operational. However, users can only modify those noncompliant resources in a way that brings them into compliance.
For example, if a cluster currently has wildcard access, users can remove 0.0.0.0/0 from the access list, but they cannot add it back once it has been removed. They also cannot add other IP addresses while the wildcard remains present. This creates natural pressure to remediate existing violations while preventing the problem from spreading to new resources.
The MongoDB Atlas Administration API provides an endpoint at /orgs/{ORG-ID}/nonCompliantResources that returns a list of all resources violating your resource policies. This provides security teams with a prioritized remediation list, making it straightforward to track progress.
Implementation strategy: Making the transition
Moving from wildcard access to blocked wildcards requires careful planning and communication to avoid creating friction that drives teams toward workarounds.
Phase 1: Discover and communicate
Begin by auditing your current environment to identify which projects and clusters currently have wildcard access. The MongoDB Atlas UI makes this straightforward; review each project’s IP access list and document wildcard usage along with who created it and when. This audit often reveals surprising findings, like production clusters that have been exposed for months without anyone noticing.
Communicate the upcoming change to all development teams well in advance of implementing the policy. Explain why wildcard access is dangerous, what will change, and what alternatives exist. Teams need time to understand the reasoning and prepare their workflows. Share examples of security incidents from wildcard access in other organizations to make the risk concrete rather than theoretical.
Phase 2: Provide alternatives
Before blocking wildcards, ensure teams have viable alternatives in place. Document how to use temporary access lists with clear examples for common scenarios. Provide the specific IP addresses or CIDR blocks for corporate VPN exit points so teams can add them to allow lists. Create documentation for setting up VPC peering or private endpoints if those are your long-term architecture goals.
Consider creating a self-service process for requesting permanent IP address additions with clear expectations for turnaround times. If security reviews take three days, teams will find workarounds. If it takes three hours, they’ll use the proper process. The key is making the right path easier than the wrong path.
Phase 3: Deploy the policy
When you’re ready to deploy, implement the wildcard-blocking policy at the organization level. Choose a time of low activity, if possible, to minimize disruption. However, remember that the policy doesn’t break existing wildcards. It only prevents new ones and modifications that would add them.
Monitor the MongoDB Atlas Activity Feed after deployment to see when the policy blocks attempted changes. Each blocked attempt represents a moment to educate teams about alternatives rather than a security incident that happened. Reach out proactively to teams whose changes are blocked to ensure they understand what happened and how to proceed.
Phase 4: Remediate
Use the noncompliant resources API endpoint to identify existing wildcards that need remediation. Prioritize production clusters and those handling sensitive data. Collaborate with application teams to identify legitimate access requirements and implement appropriate allow lists or private networking solutions.
Some clusters might have wildcards that no longer serve any purpose. They could have been added years ago, and nobody remembers why. These are the easiest remediations. Simply remove the wildcard and monitor for any broken connections.
For clusters where wildcard access is “needed,” dig deeper into the actual requirements. Often, what teams really need is temporary access for occasional troubleshooting, access from a specific set of application servers with known IP addresses, or access through a VPN that can be added to an allow list. True wildcard requirements are extraordinarily rare when examined critically.
Phase 5: Measure success
Once the wildcard-blocking resource policy is in place, measure its impact to validate progress and identify areas for improvement. Track how quickly teams can resolve access issues through approved methods. Any slowdown usually signals a need for clearer documentation or streamlined processes. Use the noncompliant resources API to monitor the reduction of existing wildcards and set clear targets for full remediation. Finally, capture the policy and its results for audit purposes; automated enforcement typically shortens audits and reduces findings compared to manual controls.
Beyond wildcards: The complete picture
While blocking wildcard access represents the most critical IP access list policy, comprehensive security requires additional layers of protection. Consider combining wildcard blocking with IP allow lists that specify exactly which addresses are permitted, empty IP access list policies that force all traffic through private networking, and region restrictions that ensure data residency compliance.
The power of resource policies lies in their composability. Each policy addresses a different security concern, and together they create a defense in depth strategy that makes unauthorized access substantially more difficult. Blocking wildcards closes the most dangerous door, but building a complete security architecture ensures you’re not leaving other doors and windows open.
Take action today
The wildcard IP address 0.0.0.0/0 is an avoidable and unacceptable risk for any production database. MongoDB Atlas Resource Policies let you eliminate it automatically without slowing developers down.
Get started by navigating to Organization Settings, then Resource Policies in MongoDB Atlas, and create a “Block Wildcard IP Access” policy. Then, paste the Cedar policy included earlier in this blog post. The policy blocks new wildcard use immediately while leaving existing configurations untouched. Then use the noncompliant resources API to identify clusters that still need remediation, and guide teams toward secure alternatives like temporary access lists and proper allow lists.
Wildcard blocking is included with every MongoDB Atlas deployment at no additional cost. There’s no reason to leave your databases exposed.
Additional resources
Next Steps
Ready to close your most dangerous security gap? Start your free MongoDB Atlas trial and implement wildcard blocking in minutes.