参数化查询必须用数组传参，哪怕只有一个值；表名、字段名、ORDER BY等结构部分需白名单校验；入口校验应强制类型转换与长度限制；所有分支路径包括日志和错误响应均需过滤敏感内容。
参数化查询必须用数组传参，哪怕只有一个值
Express里最常见的错误是把req.query.id直接拼进SQL字符串，比如query(`SELECT * FROM users WHERE id = ${req.query.id}`)。这种写法只要输入1 OR 1=1，就变成全表扫描。正确做法是用mysql2或pg驱动的参数化接口，且参数必须是数组。
-
mysql2：占位符用?，参数必须是数组，哪怕只有一个值——db.query('SELECT * FROM users WHERE id = ?', [req.query.id]) -
pg：占位符用$1、$2，顺序严格对应数组元素——client.query('SELECT * FROM logs WHERE level = $1', ['error']) - 别信“我只传数字，不会出问题”：
req.query.id永远是字符串，parseInt(req.query.id)后没校验NaN，攻击者可传1%00或1.5绕过
表名、字段名、ORDER BY不能参数化，得靠白名单硬控制
占位符只接受值，不接受结构部分。你没法写SELECT * FROM ? WHERE id = ?——mysql2和pg都会报错。这些地方必须提前定义合法范围，运行时做精确匹配。
- 字段名白名单示例：
const validFields = ['name', 'email', 'status']; if (!validFields.includes(req.query.sort)) throw new Error('Invalid sort field'); - 表名同理，别试图用配置项动态拼接，直接
switch (req.query.type) { case 'user': table = 'users'; break; } -
ORDER BY子句尤其危险：有人用ORDER BY ${req.query.sort}，结果被注入成ORDER BY id; DROP TABLE users;——分号在MySQL里允许多语句，mysql2默认开启multipleStatements: false，但别依赖它
所有分支路径都得覆盖，包括日志和错误响应
修复一个query()调用不等于修复漏洞。真正漏掉的地方往往在if/else分支、异常处理、甚至打点日志里。
- 别在
catch块里原样输出error.sql或error.sqlState——这些字段可能含原始恶意SQL，直接透出到HTTP响应体或前端控制台 - 日志记录前过滤敏感内容：
logger.info(`DB query on ${sanitizedPath}`, { params: cleanParams })，而不是logger.info('Query failed', { sql: rawSql, params: req.query }) - 注意框架封装层：Express中间件、ORM（如Sequelize）的
raw()方法、findAndCountAll({ where: sequelize.literal(...) })，这些都绕过参数化，得单独审计
应急补救优先做入口校验，别等重写DAO层
上线前没做预编译？现在没时间重构整个数据访问层。最有效动作是在路由handler之前加一层轻量校验，把90%的恶意payload拦住。
- 对ID类参数：强制转整数并检查范围——
const id = parseInt(req.query.id, 10); if (!Number.isInteger(id) || id 1e6) return res.status(400).end(); - 对搜索关键词：限制长度+禁止特殊字符——
if (req.query.q.length > 50 || /['";\/-()]/.test(req.query.q)) return res.status(400).end(); - 别用正则模糊匹配“SQL关键字”，攻击者早有绕过方案（如
uni%00on、sel/**/ect）；用硬规则卡死业务边界更可靠
真正难的不是写对一行db.query()，而是确保if分支里的SQL、错误日志里的sql字段、导出功能的raw查询、甚至监控埋点里的SQL模板，全都走同一套参数化路径。漏掉任意一处，漏洞就还在。
