WAF不能替代代码层防御，因其仅基于HTTP流量规则匹配，无法感知SQL执行逻辑，而参数化查询、最小权限和错误屏蔽才是阻断注入的根本措施。
WAF不能替代代码层防御，因为它的拦截发生在请求到达应用之前，而SQL注入的执行发生在数据库引擎解析拼接后的语句时——这两者之间存在不可逾越的语义鸿沟。
WAF只看HTTP流量，不看SQL执行逻辑
WAF处理的是原始HTTP请求，比如 GET /user?id=1' UNION SELECT password FROM users--。它靠规则匹配关键词、编码变形或行为模式做判断。但如果你的后端代码写的是 "SELECT * FROM user WHERE id = " + request.query.id，这个请求本身完全合法，WAF根本无法识别“这里即将拼出恶意SQL”。它看不到 mysqli_query() 或 sqlite_exec() 内部怎么拼、怎么执行。
- WAF拦得住
SLEEP(5)，拦不住你代码里写"SELECT 1 FROM dual WHERE " + input + " = 1" - WAF能识别
UNION SELECT，但对id=1 OR 1=1这种布尔盲注载荷，若没开高级检测规则，可能直接放行 - 所有绕过手法（大小写混写、
/**/注释分割、URL编码）都依赖WAF与后端解析器之间的差异，而这种差异永远存在
参数化查询才是切断注入链路的唯一位置
真正让输入变成“纯数据”的动作，必须发生在数据库驱动层。只有 mysqli_prepare()、pg_query_params() 或 ORM 的绑定参数机制，才能确保用户输入绝不会被当作SQL语法解析。
- 拼接字符串 → 输入是代码的一部分 → 注入成立
- 使用
?占位符 +bind_param()→ 输入被送入参数缓冲区 → 数据库引擎自动隔离处理 - 即使传入
' OR 1=1 --，在预编译语句中它只是字符串值，不会触发逻辑翻转
WAF配置再细，也救不了错误的权限和错误的错误处理
即便WAF成功拦截了99%的探测请求，只要后端还开着 root 账号、还把MySQL报错原样返回给前端，一次漏过的请求就能直接拖库。
- WAF无法限制数据库账号权限，而最小权限原则（如只授予
SELECT）能让注入即使成功也无法DROP TABLE - WAF不控制应用是否开启
display_errors，而错误回显（如MySQL Error: You have an error in your SQL syntax...）是手工注入的黄金线索 - WAF无法阻止从日志文件、备份文件、内部API等非Web入口发起的注入，这些路径根本不经过WAF
说到底，WAF是守门人，但门锁得牢不牢，取决于你在门内用的那把钥匙——也就是参数化查询、最小权限、错误屏蔽这三件套。守门人可以帮你挡住门外的试探，可一旦钥匙没拧紧，门一推就开。
