如何修复Vue+Node架构下的SQL注入漏洞_在Express中间件统一过滤-SQL-PHP中文网

sql注入漏洞源头在于服务端直接拼接sql，中间件应通过express-validator等工具做白名单校验而非字符串替换，前端过滤完全无效。

如何修复vue+node架构下的sql注入漏洞_在express中间件统一过滤

Express 中间件里直接拼接 SQL 就是漏洞源头

只要你在路由处理函数里写过类似 const sql = `SELECT * FROM users WHERE name = '${req.query.name}'` 这种代码，不管前端有没有过滤、有没有用 Vue 的 v-model.trim，SQL 注入就已经成立。Node.js 服务端才是最终执行 SQL 的地方，前端任何校验都可被绕过。

中间件本身不执行 SQL，但它可以拦截、清洗、拒绝非法请求——关键不是“加一层防护”，而是“让恶意输入根本进不到数据库操作逻辑里”。

不要在中间件里做字符串替换（比如把单引号替换成空），这属于黑盒对抗，容易漏掉边界情况（如 Unicode 编码、宽字节、注释符 -- 或 #）
不要依赖正则全局过滤（如 /[^a-zA-Z0-9\u4e00-\u9fa5]/g），业务字段可能合法含 @、.、- 等符号（邮箱、用户名、手机号）
中间件适合做「强类型校验」和「白名单放行」：比如 id 参数必须是正整数，page 必须是 1–1000 范围内的数字，status 只能是 active / inactive

用 express-validator 做参数 Schema 校验最省心

express-validator 是 Express 生态中事实标准的输入验证中间件，它不改写原始值，而是把校验结果挂到 req 上，后续路由可按需取用或中断流程。

安装后，在路由定义前加一层校验中间件：

const { body, validationResult } = require('express-validator');
<p>app.get('/api/users', 
body('name').isString().isLength({ min: 1, max: 50 }).matches(/^[a-zA-Z0-9\u4e00-\u9fa5._@-]+$/),
body('page').isInt({ min: 1, max: 1000 }).toInt(),
(req, res, next) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ errors: errors.array() });
}
next();
},
async (req, res) => {
// 此处 req.body 已确认安全，可放心用于查询
const { name, page } = req.body;
const [rows] = await db.execute(
'SELECT <em> FROM users WHERE name LIKE ? LIMIT ?, 20',
[<code>%${name}%</code>, (page - 1) </em> 20]
);
res.json(rows);
}
);</p>

matches() 比 replace() 更可靠：它明确声明“只允许这些字符”，而非“删掉那些字符”
数字类参数必须用 isInt() + toInt()，避免字符串 "1 OR 1=1" 被当作文本传入
错误响应要统一、简洁，别暴露数据库结构（如不要返回 column 'xxx' doesn't exist）

为什么不能只靠 ORM 或 query builder？

像 Sequelize、TypeORM、Knex 这些工具确实默认使用参数化查询，但它们也支持原始 SQL 模式：sequelize.query("SELECT * FROM users WHERE id = " + req.query.id) —— 只要开发者手抖拼了字符串，ORM 就形同虚设。