NoSQL-Operator-Injection

NoSQL is not no-injection. The shape of the bug differs from classical SQLi — there's no string concatenation, no quote-escaping rituals — but the consequence is the same: the attacker controls part of a database query and uses that control to read or modify data they shouldn't. The bug rides in on JSON, slips past frameworks that proudly advertise 'no SQL means no SQL injection,' and lands in production codebases that copy-paste from the official MongoDB tutorials. Express + Mongoose + body-parser is the canonical recipe; FastAPI + Motor + a Pydantic gap is the same recipe with different ingredients.

NoSQL injection appears when untrusted request data changes database filter logic instead of being treated as a literal value. It often affects JSON-heavy APIs and authentication flows.

Authentication bypass is the headline impact — `{$ne: null}` against the password field matches every user. Mass data extraction follows: boolean blind oracles via `$regex` recover field contents one character at a time. Update-side exposure is real too: an admin endpoint accepting filter JSON can be tricked into matching unintended rows for an UPDATE or DELETE. In a multi-tenant SaaS the attacker reads across tenants. In an e-commerce app they read every order.

Cast input to its expected type at the boundary, before it reaches any query layer. Strings should be strings; numbers should be numbers; nothing should be an object unless your schema explicitly allows it. The cleanest path is schema validation with Zod, Yup, io-ts, or class-validator — each one has a `.string()` validator that rejects objects outright. Mongoose's strict schema also rejects unknown operator keys, but only if you've defined the schema and use it. As a second layer, sanitize at the HTTP boundary: `express-mongo-sanitize` strips `$`-prefixed keys from request bodies. Avoid `$where` entirely (deprecated in modern Mongo, never user-controllable). Use parameterized aggregation pipelines built server-side rather than constructing them from request input. As with SQLi, the structural fix — validating types before querying — eliminates the entire bug class. Spot-fixes (escape this one field, sanitize that endpoint) leave the next vulnerability waiting.