← Concepts

阅读中文版本

NoSQL Injection

NoSQL injection slips operator objects into queries built from user input, so a document database executes conditions the developer never intended.

security

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

https://owasp.org/www-project-web-security-testing-guide/

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.