NoSQL Injection

NoSQL databases are frequently assumed immune to injection because they do not parse SQL. The underlying flaw is identical: user input crossing from the data channel into the query channel.

What changes is the shape of the payload. Instead of breaking out of a string literal with a quote, you change the type of a value — supplying an object where the application expected a scalar — and the query engine interprets your object as an operator.

This is included on a SQL injection site for two reasons. Applications commonly use both a relational store and a document store, so the same test session covers both. And the class is systematically under-tested precisely because of the assumption that it cannot happen.

CWE-943 covers this: improper neutralisation of special elements in a data query, independent of query language.

MongoDB queries are documents. {username: "admin"} matches literally. But {username: {$ne: null}} uses the $ne operator and matches any non-null username.

If the application builds {username: req.body.username} and the request body is JSON, the attacker controls the type of that value — and can supply an operator object instead of a string.

This works with URL-encoded bodies too: Express's qs parser turns username[$ne]=null into a nested object, which is why the classic payload appears in both forms.

$regex gives you the same one-bit oracle as boolean-blind SQL injection, and the same binary-search approach applies.

Anchor the pattern and test one character at a time. Each request tells you whether the value starts with the prefix you guessed.

$where evaluates a JavaScript expression against each document. If user input reaches it by concatenation, you get arbitrary JavaScript execution inside the database — the NoSQL analogue of stacked queries.

It is disabled by default from MongoDB 4.4 onward (--noscripting, and it is off in Atlas), so it is now mostly a legacy finding. Where it is enabled, it is critical.

// VULNERABLE
db.users.find({ $where: `this.age > ${req.query.age}` })

// ?age=0 || true          -> returns everything
// ?age=0; while(1){}      -> denial of service
// ?age=0 || this.password[0]=='a'   -> blind extraction

mapReduce and $accumulator have historically offered similar server-side execution and are worth checking on older deployments.

The pattern generalises to any query language assembled from strings:

Elasticsearch. Query DSL injection through a query_string field lets an attacker use Lucene syntax — * wildcards, field references, and boolean operators — to read documents outside the intended filter. Scripted fields (Painless) have offered code execution historically.

Redis. Not a query language, but EVAL with a concatenated Lua script is direct code execution, and CRLF injection into a command argument can inject additional commands entirely.

CouchDB. Map/reduce views defined from user input execute JavaScript server-side.

Cassandra (CQL). Close enough to SQL that ordinary SQL injection technique applies, minus UNION and subqueries. Parameterise the same way.

LDAP. A different grammar with the same failure mode — see filter injection with *)(uid=*.

In every case the fix is the same: parameterise or type-validate, never build the query by concatenation.

Change the type. The single highest-yield test is sending an object where a string is expected. {"$ne": null}, {"$gt": ""}, {"$nin": []} on every authentication and lookup parameter.

Try both encodings. Express's qs parser makes param[$ne]=null equivalent to the JSON form, and validation middleware frequently covers only one path.

Look for type-confusion in arrays. {"username": ["admin"]} sometimes matches where a string would not, depending on driver behaviour.

Check the error messages. Mongoose and the native driver produce distinctive errors (CastError, MongoServerError) that both confirm the backend and often reveal the query shape.

Do not assume the whole app is NoSQL. Mixed persistence is the norm. Test each endpoint for both classes.

• Validate types at the boundary. A schema validator (zod, joi, ajv, pydantic) that asserts string rejects every operator-injection payload on this page. This is the single most effective control.
• Cast explicitly. String(req.body.username) turns an object into harmless text if you cannot add a validator.
• Never compare secrets in the query. Fetch by identifier, then verify the hash in application code. This alone defeats the classic $ne login bypass regardless of typing.
• Disable server-side JavaScript. Run with --noscripting; it is the default from 4.4.
• Sanitise operator keys with express-mongo-sanitize or Mongoose's sanitizeFilter, as defence in depth rather than the primary control.
• Use the ODM's typed schema. Mongoose casts values to the declared field type, which blocks operator objects in many — though not all — positions.