Web Foundations & Databases · intermediate · ~11 min
Recognise NoSQL injection and explain correct password storage and DB least privilege.
NoSQL stores documents/key-value, and operator injection ({"$ne":null}) subverts object queries just as SQLi subverts text ones — same fix (input as data, type validation). Store passwords with slow salted hashes (bcrypt/scrypt/Argon2) and run apps under least-privilege DB accounts.
NoSQL injection bypasses authentication on object-query apps; weak password hashing turns a DB leak into mass account compromise; over-privileged DB accounts amplify every injection. All three are common, high-impact findings.
NoSQL. Document/key-value stores; JSON-like queries. Operator injection. $ne/$gt subvert object queries. Password storage. bcrypt/scrypt/Argon2 + per-password salt; never fast hashes/plaintext. Least privilege. App DB account ≠ admin, caps blast radius.
Not all databases are relational, and not all injection is SQL.
NoSQL databases (MongoDB, Redis, etc.) store documents or key/value data rather than tables. MongoDB queries are JSON-like objects.
Because queries are structured objects, injecting operators subverts them. A login that builds {username: input, password: input} can be bypassed with {"$ne": null} ("password not equal to null" → matches any). Same root cause as SQLi — untrusted input changing query structure — same fix: treat input as data, validate types, never let it become query operators.
Never store passwords reversibly. Store a slow salted hash: bcrypt, scrypt, or Argon2 (purpose-built, per-password salt, tunable cost). Plain MD5/SHA-256 is wrong — too fast, crackable at scale. Finding fast-hashed or plaintext passwords is a serious report finding.
Injection isn't limited to SQL — NoSQL operator injection has the same root and fix. Correct password storage means slow salted hashes, and least-privilege DB accounts limit damage. These round out the database-security foundation.