MongoDB stores JavaScript objects. Your query is already structured data — there is no "query string" to inject into. Which is exactly why NoSQL injection looks different from SQL injection, and why generic security linters miss it.

The attack isn't ; DROP TABLE users; --. It's this:

// POST body: { "username": "admin", "password": { "$ne": null } }
await db.collection("users").findOne({
  username: req.body.username,
  password: req.body.password,  // ← operator injection bypasses auth
});

eslint-plugin-mongodb-security is the only ESLint plugin built specifically for MongoDB/Mongoose codebases. Here's how to use it.

Install

npm install eslint-plugin-mongodb-security --save-dev

eslint.config.mjs:

import mongodbSecurity from "eslint-plugin-mongodb-security";

export default [
  {
    plugins: { "mongodb-security": mongodbSecurity },
    rules: mongodbSecurity.configs.flagship.rules,
  },
];

The three rules you need most

1. no-unsafe-query — NoSQL operator injection (CWE-943, CVSS 9.8)

Fires when a $where, $expr, or $function operator receives a value directly from user input — the exact pattern that lets an attacker inject arbitrary query logic.

// ❌ Flagged — $where with user-controlled JavaScript
db.collection("orders").find({
  $where: `this.total > ${req.query.minTotal}`,
});

// ✅ Safe — use $gt instead of $where
db.collection("orders").find({
  total: { $gt: Number(req.query.minTotal) },
});

2. no-operator-injection — Query operator in request body (CWE-943, CVSS 9.1)

When req.body (or any request property) is used directly in a MongoDB query field, an attacker can send { "$ne": null } or { "$gt": "" } as the field value to bypass authentication or extract unauthorized data.

// ❌ Flagged — req.body.password could be { "$ne": null }
const user = await User.findOne({
  email: req.body.email,
  password: req.body.password,
});

// ✅ Safe — hash and compare separately
const user = await User.findOne({ email: req.body.email });
const valid = await bcrypt.compare(req.body.password, user.passwordHash);

3. no-hardcoded-connection-string — Credentials in source (CWE-798, CVSS 7.5)

Detects mongodb:// and mongodb+srv:// connection strings with embedded credentials in source code. These get committed to git history and exposed in build artifacts.

// ❌ Flagged — credentials in source
const client = new MongoClient(
  "mongodb+srv://admin:hunter2@cluster0.example.com/mydb"
);

// ✅ Safe — from environment variable
const client = new MongoClient(process.env.MONGODB_URI);

Why a MongoDB-specific plugin

Generic security linters (eslint-plugin-security, eslint-plugin-sonarjs) don't know the MongoDB query API. They can't distinguish db.collection("users").find({ $where: userInput }) from console.log({ $where: "debug" }). The MongoDB-specific plugin knows:

• Which methods are query execution points (.find(), .findOne(), .aggregate(), .updateMany(), etc.)
• Which operators are dangerous ($where, $expr, $function, $accumulator)
• What constitutes user input in the MongoDB context

All 16 rules

If this catches something in your codebase, ⭐ star the repo — it keeps the rules maintained.

· Rule docs · ⭐ GitHub