Same concept, different databases. The payloads change but the root cause is identical.
| SQL Injection | NoSQL Injection | |
|---|---|---|
| Target databases | MySQL, PostgreSQL, MSSQL, Oracle, SQLite | MongoDB, CouchDB, Redis, Elasticsearch |
| Query language | SQL | JSON objects, JavaScript, custom query syntax |
| Classic payload | ' OR 1=1-- | {"$gt": ""} or {"$ne": null} |
| Injection point | String concatenation in SQL queries | Object injection in query filters |
| Data exfiltration | UNION SELECT, blind techniques | Operator abuse ($regex, $where), blind techniques |
| Defense | Parameterized queries / prepared statements | Input type validation, avoid $where, use ODM safely |
| Tooling | sqlmap | NoSQLMap, manual testing |
Both vulnerabilities exist because user input ends up inside a database query without proper handling. In SQL, that means string concatenation. In NoSQL (especially MongoDB), it often means passing user-controlled objects directly into query operators.
The most common NoSQL injection targets MongoDB through JSON body manipulation. If a login endpoint passes the request body directly to db.find(), an attacker can send {"username": "admin", "password": {"$ne": ""}} and bypass authentication entirely. The $ne operator matches any non-empty password.
Developers assume "no SQL = no SQL injection." Wrong. The injection surface is different — you're injecting operators and objects instead of SQL syntax — but the impact is the same: authentication bypass, data exfiltration, and in some cases (MongoDB's $where with JavaScript) even code execution.