Envoy Sidecar比边缘WAF更适合SQL注入防护，因其能拦截东西向流量、获取完整L7上下文、支持深度解析JSON/gRPC载荷，但需配置http_connection_manager、ext_authz过滤器协同后端SQL检测服务，并注意JWT校验、egress控制与日志脱敏等关键细节。
单纯在入口层配WAF拦截SQL注入，在云原生环境里已经不够用了——东西向流量（如user-service调用order-service）根本不会经过边缘WAF，而Service Mesh的Sidecar正好能拦截并检查这类请求。
为什么Envoy Sidecar比边缘WAF更适合做SQL注入过滤
边缘WAF只管南北向流量，但微服务间70%以上是东西向调用；Envoy作为Sidecar，天然接管Pod所有进出流量，且能拿到完整上下文：HTTP方法、路径、Header、JWT、甚至gRPC的metadata。更重要的是，它支持在L7层做深度解析，比如识别application/json body里的{"q":"admin'--"}这种payload，而传统iptables或四层代理完全看不到内容。
- 必须启用
http_connection_manager并配置router过滤器，否则Envoy只做透传 - 若业务用gRPC，需额外启用
grpc_json_transcoder插件，否则无法解析protobuf payload中的SQL片段 - Envoy默认不解析JSON body，要实现SQL语义检测，得配合Wasm扩展或外部校验服务（如调用轻量SQL解析器）
如何用Envoy Filter拦截典型SQL注入载荷
直接在envoy.yaml里写正则规则只能防住最基础的' OR 1=1 --，对大小写混用（SeLeCt）、注释绕过（/**/UNION/**/SELECT）或十六进制编码（0x554e494f4e）无效。真正可行的做法是两段式：先用lua或ext_authz做轻量初筛，再交由后端服务做语义分析。
- 推荐用
ext_authz过滤器，将request_headers和body发给一个独立的SQL检测服务（如基于SQLite parser的Go小服务） - 避免在Filter里做耗时解析，否则会拖慢整个调用链；超时设为
200ms以内，失败时按allow_if_no_response策略放行 - 对高危路径（如
/api/v1/search）可加硬规则：headers["content-type"] == "application/json" && body.size() < 1MB，防止大payload绕过解析
Service Mesh里SQL防护容易被忽略的三个点
很多人以为把WAF规则搬进Mesh就万事大吉，结果上线后还是被盲注打穿——问题不在技术能力，而在配置细节和信任边界。
-
JWT或service-account-token被伪造时，Envoy默认只校验签名，不校验scope字段是否含db:read，攻击者可用合法token发起恶意查询 - 出站流量（egress）默认不受控，
order-service如果直连MySQL，Sidecar根本拦不住它拼接的SELECT * FROM users WHERE id = '1' OR '1'='1' - Envoy的
access_log默认不记录原始body，想审计SQL载荷得显式开启format: "%REQ(:path)% %REQ(x-forwarded-for)% %BODY%"，且注意日志脱敏
真正难的不是加一条过滤规则，而是搞清每条流量的来路、去向、身份和上下文；Service Mesh提供了钩子，但填什么逻辑、信谁的数据、怎么兜底，得自己一环环对齐。
