NoSQL Injection: MongoDB, Elasticsearch, DynamoDB

Last updated: April 26, 2026

“NoSQL means no SQL injection” was the marketing line in 2014. NoSQL databases have their own injection class — operator injection, query manipulation, type confusion. MongoDB, Elasticsearch, DynamoDB, CouchDB each have variants. This article covers practical NoSQL injection detection, the engines where it bites hardest, and the parameterisation pattern that closes the bug class.

MongoDB injection

The most common case. If a Node.js application accepts JSON input and uses it directly:

// Vulnerable:
db.users.findOne({ username: req.body.user, password: req.body.pass })

// Attacker sends:
{ "user": { "$ne": null }, "pass": { "$ne": null } }
// Matches any document where both fields exist = login bypass

The MongoDB query language uses operators ($ne, $gt, $regex, $where) prefixed with $. If user input is treated as a query operand, operator injection is the result.

Worse, $where allows JavaScript execution server-side:

{ "user": "admin", "pass": { "$where": "return 1==1" } }

Elasticsearch injection

Elasticsearch DSL is JSON-based. If user input concatenates into the query JSON without proper escaping, attackers control the query semantics:

// Vulnerable:
GET /users/_search?q=name:${userInput}

// Attacker: name:* OR _id:*
// Returns all documents

Elasticsearch also exposes scripting languages (Painless, historically Groovy with RCE bugs). Misconfigured clusters allow remote scripts.

DynamoDB injection

DynamoDB’s filter expressions accept attribute names dynamically. If user input controls attribute paths:

// FilterExpression: contains(${attr}, :search)
// Attacker controls attr → can navigate to other attributes

Less severe than MongoDB ($where) but still bypassable.

CouchDB injection

CouchDB’s MapReduce views run JavaScript. View definitions accepting user input lead to JavaScript execution.

How to test

1. Identify NoSQL backend. Look at error messages, framework hints (Mongoose for MongoDB, Spring Data ES for Elasticsearch).
2. Test operator injection with {"$ne": null}, {"$gt": ""}, {"$regex": ".*"} in JSON inputs.
3. Test JS evaluation with {"$where": "sleep(5000)"} — time-based detection.
4. Test for query-string injection in search endpoints.
5. NoSQLMap automates much of this.

The fix

• Strict input validation — reject inputs that contain operator characters ($) when not expected.
• Parameterised queries — most NoSQL ORMs (Mongoose, Sequelize, Prisma) provide this; use them.
• Type checking — if a field should be a string, reject objects.
• Disable server-side JavaScript in MongoDB (--noscripting) and Elasticsearch (Painless only, no Groovy).
• Read-only DB users for read endpoints; the application can’t modify data via injection if the connection is read-only.

Compliance angle

• OWASP Top 10 A03 (Injection) — applies to NoSQL.
• DPDP §8(5) — NoSQL injection exposing personal data is reasonable-security failure.

The takeaway

NoSQL injection is real, well-documented, and routinely missed because “NoSQL doesn’t have injection.” Test every NoSQL-backed endpoint with operator-injection payloads. The fix is type-strict validation plus parameterised query construction.