防止SQL注入的MongoDB聚合管道$where替代方案

MongoDB聚合管道中的$where操作符本质上是把JavaScript代码当作字符串直接在数据库服务端执行，这意味着如果你把用户输入的内容拼接进$where表达式里，攻击者就能注入任意JS代码，直接操控你的数据库甚至执行系统命令。解决这个问题的核心思路只有一个：彻底放弃$where，改用MongoDB原生的聚合表达式操作符来实现同样的查询逻辑，比如$expr、$match、$regex、$and、$or、$cmp等，这些操作符都是参数化的、类型安全的，天然免疫注入攻击。

很多开发者习惯用$where是因为它灵活，可以写任意JS逻辑。但"灵活"在安全面前就是"危险"。下面我会从问题本质、替代方案、实战代码、性能对比四个维度，把这件事讲透。

先搞清楚$where到底干了什么。当你写一条聚合管道：

db.users.aggregate([
  { $match: { $where: "this.age > 18" } }
])

MongoDB会把"this.age > 18"这段字符串当作JavaScript代码，在服务端的JavaScript引擎里执行。如果你的代码是这样写的：

let userInput = req.body.age;
let pipeline = [
  { $match: { $where: `this.age > ${userInput}` } }
];

攻击者只需要传入类似"18; db.dropDatabase(); //"这样的内容，服务端就会执行删除数据库的操作。这和SQL注入的原理一模一样，只不过注入的是JavaScript而不是SQL语句。更可怕的是，JS引擎的能力远比SQL丰富，攻击者可以读取文件、发起网络请求、甚至执行系统命令。

MongoDB官方文档明确标注：$where操作符会带来性能问题和安全风险，建议尽量避免使用。但很多项目已经在用了，怎么办？下面给你具体的替代方案。

$expr是MongoDB 3.6引入的操作符，允许在$match阶段使用聚合表达式来比较文档内的字段。这是$where最直接的替代品。

假设你原来的$where写法是：

{ $match: { $where: "this.price > this.discount" } }

用$expr替代后：

{ $match: { $expr: { $gt: ["$price", "$discount"] } } }

这里$gt是"greater than"的缩写，接受一个数组参数，数组里放两个字段路径。整个表达式是结构化的JSON，不存在字符串拼接，用户输入根本没有机会注入代码。你只需要把用户输入的值作为查询条件的值传入，而不是拼进表达式字符串里：

{ $match: { $expr: { $gt: ["$price", userMinPrice] } } }

注意这里userMinPrice是一个变量值，不是字符串拼接。MongoDB驱动会自动对参数进行类型处理和转义。

$where经常被用来做字符串匹配，比如：

{ $match: { $where: "this.name.toLowerCase().includes('john')" } }

这种场景完全可以用$regex替代：

{ $match: { name: { $regex: "john", $options: "i" } } }

$options: "i"表示忽略大小写。如果用户输入是搜索关键词，你这样写：

let keyword = req.body.keyword;
{ $match: { name: { $regex: keyword, $options: "i" } } }

MongoDB驱动会对keyword进行正则转义处理，特殊字符如".*+?^${}()|[]\\"会被自动转义，不会造成正则注入。这比$where安全得多，性能也好得多，因为可以利用索引。

$where的另一个常见用法是写复杂的布尔逻辑，比如：

{ $match: { $where: "this.status === 'active' && (this.role === 'admin' || this.level > 5)" } }

用原生操作符拆解：

{ $match: {
  $and: [
    { status: "active" },
    {
      $or: [
        { role: "admin" },
        { level: { $gt: 5 } }
      ]
    }
  ]
}}

这种写法不仅安全，而且MongoDB可以对每个条件分别评估是否能用索引，查询优化器能更好地工作。而$where是一个黑盒，优化器完全看不进去。

有些场景你需要自定义比较规则，$where里可能写了复杂的JS函数。这时候可以用$cmp配合$cond来实现条件分支：

{ $match: {
  $expr: {
    $gt: [
      { $cmp: ["$score", "$threshold"] },
      0
    ]
  }
}}

$cmp返回-1、0、1分别表示小于、等于、大于。配合$cond可以实现if-else逻辑：

{ $project: {
  result: {
    $cond: {
      if: { $gt: ["$a", "$b"] },
      then: "$a",
      else: "$b"
    }
  }
}}

这些都是参数化的表达式，用户输入只作为值传入，不会被当作代码执行。

如果你确实需要一些$where才能做的复杂计算，MongoDB 4.4引入了$function操作符，但它有严格限制：只能使用预定义的函数列表，不能访问全局对象，不能执行任意代码。

{ $match: {
  $expr: {
    $function: {
      body: function(price, tax) { return price * (1 + tax); },
      args: ["$price", 0.08],
      lang: "js"
    }
  }
}}

虽然$function也执行JS，但它运行在沙箱环境中，没有访问数据库、文件系统、网络的权限。不过我个人建议，能用原生表达式解决的就不要用$function，因为它的性能仍然不如纯表达式操作符。

假设你有一个电商查询接口，原来用$where实现多条件筛选：

// 危险写法 - 存在注入风险
app.get('/products', (req, res) => {
  const category = req.query.category;
  const minPrice = req.query.minPrice;
  const keyword = req.query.keyword;

  const pipeline = [
    { $match: {
      $where: `this.category === '${category}' && this.price >= ${minPrice} && this.title.includes('${keyword}')`
    }}
  ];

  db.products.aggregate(pipeline).toArray(...);
});

改造后的安全写法：

// 安全写法 - 参数化查询
app.get('/products', (req, res) => {
  const category = req.query.category;
  const minPrice = parseFloat(req.query.minPrice) || 0;
  const keyword = req.query.keyword;

  const pipeline = [
    { $match: {
      category: category,
      price: { $gte: minPrice },
      title: { $regex: keyword, $options: 'i' }
    }}
  ];

  db.products.aggregate(pipeline).toArray(...);
});

改造后的代码有几个关键点：第一，每个条件都是独立的字段匹配，不存在字符串拼接；第二，minPrice用parseFloat转成数字，防止类型注入；第三，$regex会自动转义特殊字符。整个管道清晰可读，性能也大幅提升。

$where慢的原因有两个：一是它要启动JS引擎，每个文档都要执行一遍JS代码；二是优化器无法分析$where里的逻辑，无法选择索引，只能全表扫描。

而原生表达式操作符不同。MongoDB的查询优化器可以分析$gt、$regex、$expr等操作符，判断哪些字段可以走索引。比如上面的改造示例，如果category和price字段有索引，查询可以直接走索引，速度可能快几十倍甚至上百倍。

根据MongoDB官方的性能测试数据，在百万级文档的集合上，$where查询可能需要数秒甚至数十秒，而等价的原生表达式查询通常在毫秒级完成。这不是小优化，是数量级的差距。

说实话，有极少数场景$where确实难以替代。比如你需要对文档内嵌套数组做复杂遍历计算，或者需要调用一些自定义的JS工具函数。这种情况下，我的建议是：

第一，把$where限制在$project或$addFields阶段使用，不要放在$match里，因为$match阶段的$where会导致全表扫描，而$project阶段只处理已经过滤过的文档，影响范围小。

第二，对用户输入做严格的白名单校验，只允许特定格式的值进入管道。

第三，考虑把复杂逻辑移到应用层处理，先用原生操作符做粗筛，再在应用代码里做精筛。这样既保证了性能，又降低了数据库层面的风险。

如果你正在维护一个使用了$where的MongoDB项目，按下面的清单逐步迁移：

1. 审计所有聚合管道中的$where使用，标记出哪些是可以用原生操作符替代的。

2. 优先替换$match阶段的$where，这是性能和安全双重收益最大的地方。

3. 用$expr替代字段间比较，用$regex替代字符串匹配，用$and/$or替代布尔逻辑。

4. 确保所有用户输入都作为参数值传入，绝不拼接进表达式字符串。

5. 迁移后做回归测试，验证查询结果一致性。

6. 监控查询性能，确认索引被正确使用。

MongoDB的聚合管道本身就是一个强大的查询工具，原生操作符已经覆盖了绝大多数使用场景。$where看似方便，实则是用安全性和性能换来的"伪便利"。作为开发者，我们应该主动拥抱参数化、结构化的查询方式，这不仅是安全最佳实践，也是写出高性能代码的基本功。