Quick answer: NoSQL injection is the alteration of a query's logic in databases that do not use SQL, such as MongoDB, when user input mixes into the query object without being trusted. The classic example is operator injection: sending {"$ne": null} (not equal to null) instead of a password in a login form means "a user whose password is anything," which can bypass authentication. Data exfiltration and condition bypass are also possible with operators like $gt, $regex and $where. The difference from SQL injection is not quote escaping but the role of the input in the query object. The fix is to force the input to the expected type (it should be a string, not an object), to use the input only as a value and not as query structure, and to disable $where and server-side JavaScript.

The misconception "we use NoSQL, SQL injection does not affect us" is common and dangerous. Injection is not unique to SQL; it exists wherever user input can change the structure of a query. In MongoDB and similar document databases, this happens not with quote marks but with query operators. This guide explains how NoSQL injection works, the most common authentication-bypass and data-exfiltration examples, how it differs from SQL injection, and the correct defense.

The difference from SQL injection: operators, not quotes

In SQL injection the attacker usually breaks the query with quote marks and SQL keywords. In NoSQL, queries are often JSON-like objects, and the attack happens when the input is interpreted as an operator object instead of a value.

The classic example: a login query is built as { user: entered_name, password: entered_password }. If the application puts the request body directly into this object, the attacker can send {"$ne": null} in the password field instead of plain text. The query now means "a user whose password is not equal to null," so it matches the first user with a non-empty password and authentication is bypassed. Similarly {"$gt": ""} (greater than empty) matches all records.

The root cause here is that a field in the request body is accepted as an object when a string is expected. In JSON APIs this is especially easy because the client is free to send "password": {"$ne": null} instead of "password": "123", and if the server does not check the type it puts this into the query as is.

The most common attack forms

Technique Example Impact
Authentication bypass with $ne / $gt {"$ne": null} in the password field Login without knowing the password
Data extraction with $regex guess a field letter by letter with {"$regex": "^a"} Blind exfiltration of a secret value
$where / JavaScript injection an expression like "this.secret == x" Running logic on the server, DoS
Filter bypass with operators breaking an authorization/ownership filter with $ne Another user's data
Breaking logic with an array/object an array instead of the expected string Unexpected query behavior

$regex-based attacks are especially insidious: even if the attacker cannot see a secret value directly (for example a reset token), they can extract it by trying characters one by one (first ^a, then ^ab, ...) based on how the response changes. This is the NoSQL equivalent of SQL's blind injection. The $where operator is the most dangerous because it can go as far as running arbitrary JavaScript on the server and should generally be disabled entirely.

How it is detected

Detection begins by testing the type boundary of the input. The pentester sends an operator object ({"$ne": null}) or an array instead of a string into a field and sees whether the behavior changes: if the login unexpectedly succeeds, a different error returns, or the response time/length changes, the flaw signals itself. Character-by-character extraction with $regex proves the value can be exfiltrated in the blind case.

These tests are done by intercepting a legitimate request and editing the body; the flow we describe in our Burp Suite guide is the base here too. We cover the general logic of the injection class in detail in our SQL injection article; NoSQL injection is a different manifestation of the same root cause (input mixing with command/query structure).

The correct defense: type validation and value separation

The fix for NoSQL injection is to guarantee that the input determines only the value, not the query structure:

  • Force the input type. Fields like password and username must be strings. If such a field arrives as an object or array in the request body, reject it. A validation schema (for example with strict type definitions) does this automatically and filters out inputs like {"$ne": null} before they even reach the query.
  • Use the input as a value. Do not merge the query object directly with user input; explicitly convert the field to a string and use it that way, so an operator object loses its meaning.
  • Disable $where and server-side JavaScript. These features are unnecessary in most applications and form the most dangerous attack surface; disable them at the database level.
  • Least privilege. The database user the application connects with should only access the collections and operations it needs, so that even a successful injection has limited impact.
  • Validate input on the server. Client-side checks are not enough; the attacker sends the request directly to the API.

This approach aligns with general input-validation discipline and is the NoSQL application of the injection item in the OWASP Top 10 web application security framework.

The KAOS and DSET approach

At DSET we do not distinguish by database type in injection tests; when we see a system that does not use SQL, we specifically test NoSQL operator and JavaScript injection, because the "NoSQL is safe" misconception leaves these flaws common in the field. In our tests we inject operator objects into authentication and filter endpoints, attempt blind extraction with $regex, and do not merely detect the flaw but verify it by proving the bypassed control or the exfiltrated data. Our KAOS tool flags endpoints that accept object/operator input in fields where a string is expected and the open use of $where, but it ties the final verdict to evidence. To have your application tested against NoSQL injection, contact DSET and reach our team at Ankara Hacettepe Teknokent.

Frequently asked questions

I use MongoDB, isn't there a parameterized query? In NoSQL, the exact equivalent of SQL's "parameterized query" works differently; the core principle is that the input determines the value, not the query structure. In practice this is achieved by forcing fields to the expected type (string) and using user input in a way that cannot be interpreted as an operator. Strict input validation (reject if an object/array arrives) is the single most effective measure.

Does login bypass with $ne really work? Yes, if the server puts the password field from the request body into the query without a type check. {"$ne": null} turns the query into "a user whose password is non-empty," and you can log in with the first matching account. The fix is simple: do not process the request at all if the password field is not a string. This single validation closes most of this attack class.

Does NoSQL injection only happen in MongoDB? No. Any NoSQL system where user input can mix into the query or command structure (document, key-value, graph databases) has similar risks; only the operators and syntax change. The principle is the same everywhere: use input as a value, not as structure, and disable features that run server-side code.

Sources