API网关是唯一能强制拦截所有南北向流量的节点，但必须严格按「验签→解析body→递归扫描JSON字符串」顺序执行，且Nginx需启用ModSecurity并配置SecRequestBodyAccess On，Envoy Sidecar才适用于东西向防护。
API网关不能单靠关键词匹配拦住SQL注入，但它是唯一能强制拦截所有南北向流量的节点——前提是签名校验、请求体解析、规则执行三者顺序正确，且 JSON 递归扫描不漏深层字段。
Spring Cloud Gateway 的 GlobalFilter 必须按「验签 → 解析 body → 扫描字符串」执行
常见错误是把 SQL 检测逻辑放在验签前，导致攻击者用伪造 appKey 直接触发检测服务，既绕过身份约束，又可能耗尽线程资源。真实可行链路只能是：
- 从
exchange.getRequest().getQueryParams()或 header 中提取appKey，查配置中心拿到对应appSecret - 用
timestamp和nonce校验签名原文（二者必须字典序拼接），超时（>300000ms）或重复即拒 - 验签通过后，才调用
exchange.getRequest().getBody()获取Flux<DataBuffer>，避免body.asString().block()阻塞式读取 - 对
application/json类型，用JsonNode加载后递归遍历所有JsonNodeType.STRING节点，禁用toString()全文扫描
Nginx 网关无法自动解析 POST body，必须显式启用 ModSecurity 并配置 SecRequestBodyAccess On
if ($args ~* union) 这类规则对 JSON 请求完全无效，因为 $args 只含 query string，不包含 POST body。要真正看到 JSON 字段里的 "name": "admin'--"，必须：
- 启用
modsecurity模块，并在配置中明确设置SecRequestBodyAccess On - 确保
SecResponseBodyAccess Off，避免响应体误判干扰 - URL 解码至少一次：攻击者发
%27OR%201%3D1，网关需解成'OR 1=1才能命中规则 - 不要把规则写在
http或server块顶层——Nginx 会报错；必须放在具体location内
Envoy Sidecar 是东西向 SQL 防护的唯一有效路径
边缘网关（如 SCG、Kong）只管南北向流量，服务间调用（user-service → order-service）根本不会经过它。而 Envoy Sidecar 部署在 Pod 内，能拦截所有进出流量，但默认不解析 body：
- 必须在
http_connection_manager中为路由显式配置per_route_config+ext_authz过滤器 - 设置
with_request_body: { max_request_bytes: 1048576 }，否则拿不到完整 payload - 推荐将可疑请求转发给独立 SQL 解析服务（如基于
libinjection的轻量级解析器），而非在 Envoy 内做正则匹配 - 注意：gRPC gateway 将 JSON 转 protobuf 后透传，若网关未解析原始 JSON，
UNION SELECT会直接穿过
最常被忽略的一点：所有网关层规则都依赖「请求体真被解析了」。如果 Content-Type 是 application/json 却没配 JSON 解析器，或者用了 jsonNode.toString() 导致嵌套结构（如 {"filter": {"$where": "this.x==1"}}）完全不可见，那所谓防御就只是个开关摆设。
