What is NoSQL Injection?

NoSQL injection is an injection flaw affecting databases such as MongoDB and other document, key-value or graph stores. NoSQL does not mean that injection is impossible. The syntax is simply different: an attacker may submit query operators, JavaScript expressions or unexpected data types instead of a normal value.

A login endpoint might expect a string for the password but accept an object containing a comparison operator. If this object is passed directly into the database query, it can change the condition and bypass authentication. Other attacks extract records, alter filters or trigger expensive queries.

How can NoSQL injection be prevented?

• - Validate both the type and permitted content of every input before building a query.
• - Use the database driver's safe query APIs and do not merge request objects into query objects.
• - Disable server-side scripting where it is not required and restrict the database account.
• - Test JSON and nested parameters as carefully as conventional form fields.

Code example: never copy a request object into a MongoDB query

Vulnerable: The client can submit an object containing operators.

const user = await users.findOne({
  email: req.body.email,
  password: req.body.password
});

Safer data flow:

if (typeof req.body.email !== 'string' ||
    typeof req.body.password !== 'string') {
  return res.status(400).end();
}

const user = await users.findOne({ email: req.body.email });
if (!user || !await argon2.verify(user.passwordHash, req.body.password)) {
  return res.status(401).end();
}

Type validation prevents an operator object from reaching the query where a string is expected. Passwords are not compared inside the database query; a dedicated password-hashing function verifies the stored hash.

How does it differ from SQL injection?

SQL injection often manipulates a query string. NoSQL injection frequently abuses structured objects and type confusion. Both result from crossing a trust boundary without safely constraining the data.

Which variants exist?

• Operator injection:
  a scalar value arrives as an object containing comparison or logical operators and changes record selection.
• Syntax injection:
  input enters a textual query language, regular expression or search syntax and escapes its intended context.
• Server-side JavaScript:
  legacy or explicitly enabled database features evaluate an attacker-influenced expression.
• Aggregation and projection:
  manipulated pipelines or field lists expose additional information or execute expensive operations.

A typical mistake in a JSON API

An API may expect {"username":"anna"} but merge the request directly into a query object. If a client sends a nested object instead of a string, the database driver may interpret it as an operator. A schema that enforces type, length and permitted structure prevents that change from a data value to a control object. Character filtering alone cannot secure structured input.

Impact and detection

NoSQL injection can bypass authentication queries, read unrelated documents, broaden searches, alter data or cause denial of service through expensive regular expressions and aggregation. Tests therefore vary data types, nesting and operators, not only characters. Changed result counts, timing and database errors provide clues. Monitoring may reveal unexpectedly broad queries, expensive expressions and repeated type-conversion failures.

Secure implementation

Request DTOs or JSON schemas should reject unknown fields and enforce whether a value is a string, number or Boolean. The application constructs a fixed query object from validated values and never accepts a complete client-supplied filter. Flexible searches need allowlists for fields and operators plus limits on nesting, result size and execution time. Narrow database permissions reduce impact if a flaw remains.