Node.js如何防止MongoDB执行注入式查询？-MongoDB-PHP中文网

mongodb本身无sql注入，但应用层将用户输入直接拼入查询对象会引发nosql注入；需对字段严格校验类型与格式，禁用$where、$regex等高危操作符，并实施四层纵深防护体系。

node.js如何防止mongodb执行注入式查询？

直接传`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, '')清理

示例：

php版微信js-sdk支付接口类

下载

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+）都是潜在入口