Node.js防止MongoDB注入式查询的实用方法

MongoDB 本身并不存在传统意义上的 SQL 注入，但如果在应用层直接将用户输入原封不动地塞入查询对象，就会引发 NoSQL 注入风险。要有效防范这一威胁，必须对字段进行严格的类型与格式校验，禁用 $where、$regex 等高危操作符，并在此基础上构建一套四层纵深防护体系——这几个环节缺一不可。

直接传 req.body 进 findOne() 就是高危操作

将用户输入原样传递给 findOne()、find() 或 updateOne() 的第一个参数，相当于把查询逻辑的控制权拱手交给了攻击者。MongoDB 驱动不会做任何解析或拦截，它只是将 JavaScript 对象序列化为 BSON 发送给服务端——例如 { "$ne": null } 会被照单执行，这并非“无效语法”，而是一条合法的查询指令。

常见的翻车场景：db.users.findOne({ username: req.body.username })，攻击者提交 {"$ne": null}，直接绕过登录校验；Model.find(req.query.filter)，前端传 {"status": {"$in": ["active", "deleted"]}} 看着还行，但没人拦得住 {"$where": "sleep(1000)"}。

• 所有主流驱动（Node.js 原生驱动、Mongoose）行为一致：不校验、不重写、不拒绝非法结构
• Mongoose 的 strict: true 默认只限制写入时的 schema 外字段，对查询条件完全无感
• 别信“用了 Mongoose 就安全”——Model.find(req.body) 在任何版本下都等于裸奔

对字符串字段必须做 typeof + 正则双校验

username、email、title 这类字段，业务上本就应该是纯字符串，那就得用代码把它钉死。类型校验是第一道防线，格式校验是第二道，缺一不可。

• 先用 typeof value === 'string' 排除对象、数组、null、undefined
• 再用正则限定内容范围：/^[a-zA-Z0-9_]{3,20}$/ 比 /^.+$/ 安全得多
• 主动拒绝空字符串和前后空白：value.trim() === '' 需单独判断
• Unicode 控制字符、零宽空格、BOM 头也要过滤，可用 value.replace(/\p{C}/gu, '') 清理

示例：

if (typeof req.body.username !== 'string' || !/^[a-zA-Z0-9_]{3,20}$/.test(req.body.username.trim())) {  return res.status(400).json({ error: 'Invalid username' });}

$regex、$where、$expr 必须隔离用户输入

这几个操作符是 NoSQL 注入的“特权通道”。哪怕前面做了严格的字符串校验，一旦放开它们接收原始输入，整个防御体系就形同虚设。

• $regex 必须配合 $options: 'i'，且对用户输入做转义：req.query.q.replace(/[.*+?^${}()|\[\]\\]/g, '\\$&')
• $where 应彻底禁用——它允许执行任意 JavaScript，而且不走索引，性能和安全双崩
• $expr 若必须使用，只能接受白名单内的固定表达式，不能拼接用户输入
• 不要用 JSON.parse() 二次解析用户输入——可能触发原型污染或正则 DoS

错误写法：{ name: { $regex: req.query.q } }；正确写法：

const escaped = req.query.q.replace(/[.*+?^${}()|\[\]\\]/g, '\\$&');db.users.find({ name: { $regex: escaped, $options: 'i' } });

别依赖“过滤 $ 符号”或“黑名单操作符”

简单粗暴地删掉 $ 或禁止 $ne、$gt 等关键词，是典型的伪方案。MongoDB 会安静忽略无效操作符，导致查询逻辑意外放行数据。

• 用户输入 {"status": {"$ne": "deleted"}}，过滤后变成 {"status": {"ne": "deleted"}}，MongoDB 不报错也不匹配，等价于 {}——查出全部文档
• 攻击者可用 Unicode 编码绕过，比如 \u0024ne 代替 $ne
• 黑名单永远追不上新操作符，$text、$geoWithin、$function（MongoDB 4.4+）都是潜在入口

真正有效的做法，是从源头切断恶意结构的传播路径：只允许你明确定义的字段名和值类型进入查询对象，其余一律拒之门外。复杂点在于字段语义各异——搜索字段要支持模糊匹配，ID 字段要校验 ObjectId 格式，时间范围字段要转为 Date 实例。没有银弹，只有按字段逐个收口。