SQL 注入防护清单：参数化查询、最小权限与审计策略
SQL 注入并不是“老漏洞”，而是“老问题的新写法”。越是业务复杂、动态查询多的系统，越容易在边角逻辑里重新出现拼接 SQL。防护要靠体系，不靠单点补丁。
1. 参数化查询是底线，不是建议
核心原则只有一个：数据和 SQL 结构必须分离。用户输入只能作为参数值，不能参与 SQL 语法拼接。无论你用原生驱动还是 ORM，这条都不能破。
- 正确：`WHERE id = ?` + 参数绑定
- 错误：`WHERE id = ` + 用户输入拼接
2. ORM 也会踩坑，特别是动态排序和筛选
很多注入来自“以为 ORM 自动安全”。高风险点通常是：
- 动态 `ORDER BY` 字段直接拼接
- 动态表名、列名未做白名单
- 原生 SQL escape 使用不当
建议对可变字段做白名单映射，不要把前端传来的字符串直接放进查询模板。
3. 数据库权限按“最小可用”拆分
即使出现注入，也要让破坏面受限。推荐至少拆分：
- 只读账号：查询报表、检索接口
- 读写账号：核心业务写操作
- 运维账号：DDL、迁移、管理命令（线上禁用）
应用账号不要有 `DROP`、`ALTER` 等高危权限。
4. 输入校验和 WAF 是“第二道防线”
参数化是第一道。输入校验和 WAF 用于拦截异常模式和高风险流量，但不应替代代码层防护。
- 关键参数做类型和长度约束
- 异常 payload 命中后进入风控与告警
- 高危路径配置更严格的速率限制
5. 审计和回放能力决定恢复速度
防护之外，还要能快速确认是否被利用：
- 记录 SQL 执行摘要、请求 ID、用户 ID
- 保留慢查询与异常错误栈
- 高危操作触发实时告警
安全工作的目标不是“绝不出问题”，而是“出了问题可定位、可遏制、可恢复”。
上线前自查清单
- 所有写接口已排查拼接 SQL 风险。
- 动态查询字段全部经过白名单映射。
- 数据库账号按最小权限拆分完成。
- WAF/审计日志可关联到应用请求链路。
把这四项做扎实，SQL 注入风险会显著下降。