Spring Security 不拦截 SQL 注入，真正有效的是参数化查询（MyBatis #{}、JPA 命名参数、PreparedStatement）和数据库最小权限；WAF 拦不住需开启 SecRequestBodyAccess On、proxy_pass_request_body 或云 WAF 的 JSON 解析与语义引擎。
Spring Security 本身不拦截 SQL 注入，WAF 也拦不住没传请求体的 POST 请求——两者必须各守一段边界，且配置错一个环节，整个防御链就断在中间。
Spring Security 不该也不负责 SQL 注入拦截
它压根不碰 SQL 构造过程。你在 @RestController 里写 String sql = "SELECT * FROM user WHERE name = '" + name + "'"，再配十个 SecurityFilterChain 都无效。真正起作用的只有：
- MyBatis 必须用
#{}，禁用${}；JPA 查询必须用命名参数:name，不能拼字符串 - JDBC 原生调用必须走
PreparedStatement，绝不能用Statement+ 字符串拼接 - 数据库账号权限最小化：查用户只给
SELECT user.*，别开DROP或跨库权限
WAF 拦不到 SQL 注入，大概率是请求体没传过去
现代 API 大量走 JSON POST，而 Nginx 默认不把原始 body 传给 ModSecurity。不开 SecRequestBodyAccess On，所有 REQUEST_BODY 规则（包括 OWASP CRS 的 REQUEST-942-APPLICATION-ATTACK-SQLI.conf）全失效。
-
SecRequestBodyAccess On必须写在modsecurity.conf全局块，不能只塞进location - 后端是 PHP-FPM：在
location ~ \.php$块加fastcgi_pass_request_body on; - 后端是
proxy_pass（如 Node.js/Java）：对应location加proxy_pass_request_body on; - 云 WAF（如腾讯云、阿里云）需单独开启「解析 POST Body」或「JSON 解析」开关，否则
{"id":"1' OR 1=1--"}直接被当普通字符串放过
语义引擎不开，正则规则等于摆设
单纯匹配 union|select|sleep 拦不住 UnIoN%09SeLeCt、SEL/**/ECT、0x554e494f4e 这类变形。云 WAF 的「SQL 注入防护」开关默认只启关键字正则，语义分析引擎（如 Libinjection）往往要手动打开。
- 验证是否真生效：用
curl -v "https://yoursite.com/?id=1%20AND%20SLEEP(3)"测试，同时查 WAF 日志里是否有带fingerprint字段的拦截记录 - 高危路径（如
/api/v1/user）建议加精准规则：request_uri matches "/api/.*user.*" and libinjection_is_sqli == true - 自定义规则别写
args contains "OR 1=1"——它会误杀?filter=ORANGE；应先初筛（如含单引号+括号），再交语义引擎判断
Spring Cloud Gateway 可补 WAF 漏洞，但不能替代参数化查询
如果你用微服务架构，可以在网关层用全局过滤器统一清洗参数，比如对所有非富文本字段做基础标签清理：replaceAll("<script>，或用 <code>Jsoup.clean()</script> 白名单过滤。
- 这能快速兜底绕过 WAF 的简单 payload（如 GET 参数里的
' OR 1=1 --） - 但它对 JSON body 中的深层嵌套字段（如
{"query":{"filter":"' OR 1=1--"}}）无能为力，除非你手动解析整个 JSON 树 - 最危险的是：有人以为加了网关过滤就安全了，结果在业务服务里又写了
String.format("... %s ...", userInput)—— 防御层级错位，等于白忙
真正容易被忽略的点是：WAF 日志里报 failed to open stream 却没人去看，规则根本没加载；或者语义引擎开着，但 JSON 解析关着，导致 90% 的真实攻击流量完全不进检测流程。
