必须采用「API网关 + Envoy Sidecar」双层拦截：网关负责南北向验签优先，Sidecar负责东西向语义解析兜底；Spring Cloud Gateway需严格按「验签→SQL扫描」顺序执行GlobalFilter，Envoy须启用http_connection_manager、router、ext_authz三过滤器并配置with_request_body，检测服务应基于libinjection等做词法语法解析而非正则匹配。
不能只靠网关或只靠服务网格——SQL注入在云原生里必须用「API网关 + Envoy Sidecar」双层拦截，且职责必须明确：网关管南北向、验签优先；Sidecar管东西向、语义解析兜底。
Spring Cloud Gateway 必须按「验签 → SQL扫描」顺序执行 GlobalFilter
常见错误是把 SQLInjectionFilter 放在签名验证之前，导致攻击者用伪造的 appKey 直接触发检测逻辑，绕过身份约束。真实流程只能是：
- 先从
request.getHeaders().get("X-App-Key")或 query 中提取appKey，查配置中心拿到对应appSecret - 用
timestamp和nonce校验签名原文（二者需按字典序拼接） -
timestamp与网关当前时间差 ≤ 300000ms（5 分钟），超时直接拒 -
nonce需 Redis 去重，5 分钟内重复即拒 - 只有验签通过，才调用
Flux<databuffer></databuffer>异步读取 body 并递归遍历所有字符串字段
对 JSON Body，parseObject(requestBody) 只取顶层字段，像 {"filter": {"name": "admin' OR 1=1--"}} 会完全漏掉。必须用 JsonNode 加载后，手动遍历所有 JsonNodeType.STRING 节点，或调用 findValuesAsText(".*")。
Envoy Sidecar 必须启用 http_connection_manager + router + ext_authz 三过滤器
Envoy 默认只是透传代理，不解析 L7 内容。若没显式配置这三项，ext_authz 连 request body 都拿不到，SQL 检测形同虚设：
-
http_connection_manager：必须启用，否则无法识别 HTTP 方法、Header、body 等 L7 信息 -
router：必须配置，否则请求不会被路由到后端，ext_authz无法触发 -
ext_authz：需显式设置with_request_body: { max_request_bytes: 1048576 }，否则 body 为空 - 若业务用 gRPC，还需额外启用
grpc_json_transcoder插件，否则 protobuf payload 中的 SQL 字段无法提取
检测服务推荐用轻量 Go 实现，调用 libinjection 或 SQLite parser 做词法+语法解析——别在 Filter 里写 Lua 正则匹配，0x554e494f4e（UNION 十六进制）和 /**/UNION/**/SELECT 会直接绕过。
云厂商 WAF 的语义分析引擎必须手动开启并验证生效
阿里云/腾讯云 WAF 的「SQL注入防护」开关默认只启用了基础正则规则，对注释混淆、大小写混用、URL 编码等变形毫无抵抗力。语义分析引擎不是默认开启的，且必须配合 JSON 解析才能生效：
- 检查控制台路径：
WAF 控制台 → Web 攻击防护 → SQL 注入 → 动作设为“拦截”，禁用“仅记录”模式 - 确认已开启
JSON 解析开关，否则{"q":"admin'--"}这类 payload 会被当普通字符串放过 - 指定数据库类型（MySQL / MSSQL），否则误报率飙升
- 主动探测：
id=1%20AND%20SLEEP(3)应返回403且响应头含X-WAF-Action: blocked - 查日志：搜索
sql_injection并筛选action: block，确认有带fingerprint字段的条目（语义引擎生成）
真正容易被忽略的是：语义分析引擎常与「智能防护」或「AI 模式」强绑定，单独开 SQL 注入规则组 ≠ 开启语义层。
