SQL注入防护需四层卡点：①参数化查询切断语义绑定；②输入验证快速失败；③最小权限与执行隔离；④错误与日志脱敏。WAF仅作辅助，不可替代代码层防御。
SQL注入不是靠“加个单引号试试”就能防住的，核心在于切断用户输入与SQL语义的绑定关系。真正有效的防护不是堆砌规则，而是从数据流向、执行边界、权限控制三个层面系统性隔离——输入不参与拼接、执行不依赖字符串、权限不越界授权。
参数化查询：从源头掐断语义污染
这是最根本、最不可替代的防线。只要SQL语句结构固定，变量仅作为纯数据传入，数据库驱动天然剥离其执行意图。
- ✅ 正确做法：用预编译占位符（如?、:name、@param），由数据库驱动完成类型校验与转义
- ❌ 错误做法：用字符串格式化（f-string、.format()、+拼接）组装SQL，哪怕做了手动过滤也形同虚设
- 注意：ORM的filter(name=xxx)默认是参数化；但extra()、raw()、annotate()中含字符串模板时仍可能触发注入
输入验证与上下文感知过滤
验证不是为了“拦住恶意字符”，而是确保输入符合业务预期的格式和范围——它不能替代参数化，但能快速拦截明显异常请求，降低攻击面。
- 对ID类字段：严格限定为正整数，用int()强转+异常捕获，拒绝非数字输入
- 对用户名/邮箱：用白名单正则（如^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$），不依赖黑名单式替换
- 关键原则：验证必须在参数化之前做，且只用于快速失败（fail-fast），不用于“清洗后拼接”
最小权限原则 + 执行环境隔离
即使某处逻辑失守，也要让攻击者无法走远。数据库账号权限、应用连接池配置、甚至SQL运行上下文都要做减法。
- Web应用数据库账号禁止CREATE、DROP、ALTER、UNION SELECT、LOAD_FILE()等高危权限
- 读写分离场景下，查询接口只连只读账号，且该账号仅授予所需表的SELECT权限
- 避免在SQL中调用存储过程或自定义函数（尤其含动态EXEC的），它们容易成为注入跳板
错误信息与日志脱敏
详细报错（如"You have an error in your SQL syntax near 'xxx'"）等于给攻击者递导航地图。生产环境必须关闭数据库原始错误回显。
- Web框架中统一配置DEBUG=False，用通用错误页替代技术细节
- 日志记录SQL时，自动替换参数值为[REDACTED]，避免敏感数据落盘
- 可部署WAF作为辅助层，但仅限识别已知payload模式，不能替代代码层防御
基本上就这些。防护不是靠某个“神奇函数”一招制敌，而是让输入进不来语义层、进来也跑不动、跑动了也拿不到东西、出了事还看不出端倪——四层卡点，缺一不可。
