NoSQL injection
NoSQL injection occurs when an application allows untrusted input to alter a database query's operators or meaning.
What it means
NoSQL injection occurs when an application allows untrusted input to alter a database query's operators or meaning. Different databases expose different query languages and object structures. Accepting an arbitrary caller-provided query object can be dangerous even when no SQL text exists.
A practical example
A login service expects a username string but receives an object containing a query operator. It rejects the wrong type and constructs its own fixed query structure instead of passing the incoming object directly to the database driver.
What to check
Validate field types and accepted operators, use supported driver patterns, and restrict database privileges. Review features that evaluate expressions or server-side code and require stronger justification for their use.
A common pitfall
A database being nonrelational does not remove injection risks. Replacing string concatenation with unrestricted query objects may simply move the trust problem to operator selection.
Think it through
Why reject an object where a username string is expected?
Answer: Its structure might introduce database query operators rather than represent the intended literal username.
Structured input can still become query logic
A fictional catalogue service accepts a product category in a JSON request. The intended value is a string, but the database driver also understands structured query operators. If the application forwards the supplied object directly into a query, a caller may influence query behavior rather than merely naming a category. Avoid assuming that injection requires a SQL string.
Define an explicit request schema and construct the database operation from application-owned fields. The caller should not choose arbitrary operators, field names, or executable expressions. A data-transfer object can make the boundary visible: the external request describes a permitted business action, and server code translates that action into a supported query.
Query safety and data access remain distinct. A correctly typed category filter can still return another tenant's products if the query lacks the authorized tenant condition. Likewise, a collection-wide administrative credential increases the effect of a mistake. Restrict both the query interface and the database account's capabilities.
Compare two request contracts
For a paper exercise, define a catalogue search that accepts category, minimum price, and page size. Give each a type and permitted range. Compare it with an endpoint that accepts an arbitrary database query object. Explain which decisions the server retains in the first design and gives away in the second.
Review aggregation pipelines, filter builders, and administrative tools as separate entry points. A safe ordinary search does not cover an export feature that forwards arbitrary query structures. Use dummy records in an isolated database for demonstrations, and describe the specific operator or structural boundary involved without collecting real customer data. The repair should preserve supported search features while preventing clients from selecting database behavior beyond that contract.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: NoSQL Security