sql注入防护核心是不信任用户输入、不拼接sql语句；需坚持参数化查询为主，辅以输入校验、权限最小化、错误信息管控及waf兜底，并养成安全编码习惯。
SQL注入防护的核心是永远不信任用户输入，永远不拼接SQL语句。只要守住这两条底线，95%以上的注入风险就能被拦在门外。下面从原理到实操，讲清楚真正管用的防护手段。
参数化查询：最可靠的第一道防线
参数化查询（也叫预编译语句）让SQL结构和数据彻底分离。数据库先解析SQL模板，再把用户输入作为纯数据绑定进去，根本不会当作代码执行。
- PHP中用PDO的
prepare()+execute()，不要用mysql_query()拼接字符串 - Java里用
PreparedStatement，别用Statement直接拼接 - Python用
cursor.execute("SELECT * FROM user WHERE id = %s", [user_id])，禁用f"WHERE id = {user_id}"
输入校验与过滤：辅助但不能依赖
校验是锦上添花，不是救命稻草。比如手机号只允许数字、邮箱用标准正则验证，能快速拦截明显异常输入。
- 对ID类字段，优先转成整型（如
int(user_input)），强制截断或报错 - 对搜索关键词等需保留符号的场景，可白名单过滤（如只允许中文、英文、空格、常见标点），不建议黑名单
- 注意：前端校验可绕过，后端必须重复校验；正则过滤不能替代参数化查询
权限最小化与错误信息管控
即使有漏洞，也要让它“打不着要害”。数据库账号只给必要表的读写权限，绝不用root或sa连接应用。
- Web应用连接数据库的账号，仅授予
SELECT/INSERT/UPDATE对应业务表，禁用DROP/UNION/LOAD_FILE等高危操作 - 关闭数据库详细错误提示（如MySQL的
sql_mode=STRICT_TRANS_TABLES+ 应用层捕获异常），返回通用提示如“操作失败”，不暴露表名、字段名、数据库版本 - 日志中记录原始请求参数，便于事后分析，但不记录敏感字段（如密码、身份证号）
WAF与深度防御：给系统加一层“保险”
Web应用防火墙（WAF）可识别常见注入特征（如1' OR '1'='1、UNION SELECT），适合兜底拦截漏网流量。
- 云厂商WAF（如阿里云、腾讯云）或开源方案（ModSecurity + OWASP CRS）可快速接入
- 注意：WAF规则可能误杀，上线前要充分测试；它不能替代代码层防护，只是纵深防御一环
- 定期用
sqlmap -u "http://site.com?id=1"做自查（测试环境！），验证防护是否生效
基本上就这些。不复杂，但容易忽略细节。真正防住SQL注入，靠的是习惯——写每一行查询时，都下意识问一句：“这个变量，我敢把它当数据传，还是当代码拼？”
