API网关是SQL注入第一道防线，因其能前置校验所有请求、统一管控微服务、覆盖非JSON接口，并与签名验证联动实现溯源告警。
移动端API的SQL注入不能只靠后端ORM或参数化查询兜底——攻击者根本不用打开App，用curl或Postman就能绕过客户端直打你的接口。签名校验必须和SQL特征检测绑死，否则签名合法但参数含UNION SELECT，等于给黑客发了张VIP通行证。
为什么网关层签名必须强制绑定timestamp和nonce
只校验sign参数是无效的。攻击者能重放旧请求，也能固定nonce反复修改timestamp试探窗口。真实防护必须满足：
-
timestamp为long类型，且与当前服务器时间差 ≤ 300000（5分钟），超时直接拒 -
nonce长度 ≥ 8，且网关需在Redis或本地缓存中记录最近5分钟所有已用nonce，重复即拒 - 签名原文必须包含
timestamp和nonce，且二者参与字典序拼接——否则攻击者可构造nonce=abc×tamp=1746729600000长期复用 -
appSecret绝不能出现在请求头或URL里；网关须通过appKey查配置中心动态获取，避免硬编码泄露
Spring Cloud Gateway里怎么嵌入SQL特征扫描
默认GlobalFilter不识别SQL注入，得自己加逻辑。重点不是穷举所有变体，而是拦截高频攻击载荷：
- 遍历
request.getQueryParams()和ServerWebExchange.getFormData()所有值，检查是否含：'、"、;、--、#、UNION、SELECT、INSERT、EXEC（忽略大小写） - 对JSON Body，用
Flux<databuffer></databuffer>异步读取后解析为JsonNode，递归遍历所有字符串字段 - 命中规则时返回
400 Bad Request，记录原始参数用于溯源；不抛异常、不打印堆栈，防止信息泄露 - 正则匹配布尔盲注如
OR '1'='1时，必须加Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE
签名验证和SQL检测为什么必须串联执行
顺序错了就等于开门揖盗：
- 先验签名再扫SQL：如果签名非法，连参数都不可信，直接401，不进SQL检测流程
- 签名合法但SQL检测失败：说明密钥可能已泄露，或客户端被中间人劫持，此时要触发告警（如发企业微信通知+写审计日志），不能只返回400
- 绝对禁止“先扫SQL再验签”：攻击者可伪造任意
appKey发带恶意SQL的请求，绕过签名校验环节 - 非JSON接口（如
application/x-www-form-urlencoded或GET参数）同样要覆盖，这类接口常被用于搜索、分页等高危场景
最易被忽略的一点：网关层检测只是第一道过滤，它不替代后端的参数化查询。哪怕网关放过某个看似无害的order by参数，后端也必须用PreparedStatement或ORM白名单机制处理，否则仍可能被用于报错注入或时间盲注。
