NoSQL databases such as MongoDB do not use SQL, but they are still vulnerable to injection. NoSQL injection happens when user input is placed into a database query object or operator, changing what the query does.

Many teams assume that moving away from SQL removed injection risk. It did not.

How it happens

Web frameworks often turn JSON bodies or query strings straight into objects. If an attacker sends an operator such as {"$ne": null} instead of a plain value, a login query that should match one user can match any user.

Server-side JavaScript evaluation in some databases adds a further route to injection.

Why it matters

• Login bypass without a password.
• Reading or enumerating records the user should not see.
• Denial of service through expensive queries.

How to prevent it

• Cast and validate input types: a username must be a string, not an object.
• Reject keys that start with $ or contain . in user-supplied objects.
• Use your driver's query builders instead of passing raw request objects.
• Disable server-side JavaScript execution in the database if you do not need it.

How Vooki Pro helps

• Tests request parameters and JSON bodies for NoSQL injection.
• Scans REST APIs imported from OpenAPI, Postman, HAR, cURL, Bruno or Insomnia, where NoSQL injection often hides.
• Reports the exact request that triggered the finding, with remediation guidance.
• Lets you retest the finding once the fix is deployed.

Frequently asked questions

Can MongoDB be vulnerable to injection?

Yes. If user input is placed into a query object without type checks, attackers can inject operators such as $ne or $gt and change the query's meaning.

How do I prevent NoSQL injection?

Validate input types, reject keys starting with $, use your driver's query builders, and never pass raw request objects into database queries.

Related: Blind SQL injection: how it works and how to stop it · Server-side template injection (SSTI)