NoSQL Injection
NoSQL injection slips operator objects into queries built from user input, so a document database executes conditions the developer never intended.
Definition
NoSQL injection is the class of attacks that exploit query construction in document and key-value stores, typically by injecting query operators or manipulating types when input is passed through unchecked.
Context and scope
It appears wherever a request body or query string is merged directly into a database filter without validation.
Common misconceptions
- document databases are immune because they do not use SQL
- only string concatenation enables injection
Anti-patterns
- passing a request body object straight into a query filter
- trusting that a value is a string because the client usually sends one
Related concepts
Related examples
Authoritative source
Definition
NoSQL injection is the class of attacks that exploit query construction in document and key-value stores, typically by injecting query operators or manipulating types when input is passed through unchecked.
It appears wherever a request body or query string is merged directly into a database filter without validation. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
An attacker can send an operator such as a not-equal condition in place of a value, turning a login check into a match against almost every record.
The fix is to validate and coerce input types before building a query and to reject objects where a scalar is expected, rather than relying on the driver to sanitise.
Trade-offs and alternatives
Same class of risk applies to sorting, projection, and update operators, not only to the filter, so every field that reaches the query layer needs a schema. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that document databases are immune because they do not use SQL. Another is that only string concatenation enables injection. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to passing a request body object straight into a query filter and to trusting that a value is a string because the client usually sends one. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include LDAP Injection, HTTP Response Splitting, Rainbow Tables and Lookup Attacks.