移动端App后端API的SQL注入防护必须在服务端入口完成，覆盖网关层SQL特征扫描与签名强绑定、参数解析层字段级白名单校验、数据库执行层强制参数化查询三层防线。
移动端App后端API的SQL注入防护，不能依赖客户端过滤或“ORM用了就安全”这种错觉——攻击者从Burp Suite直发请求，绕过App本身，所有校验必须在服务端入口完成，且至少覆盖三层：网关层拦截、参数解析层白名单、数据库执行层强制参数化。
API网关层必须做SQL特征扫描 + 签名强绑定
Spring Cloud Gateway等网关是第一道真实防线，不是可选项。只做签名验证而跳过SQL特征检测，等于给带刀的人发了门禁卡却不搜身。
- 对
request.getQueryParams()和ServerWebExchange.getFormData()中每个值，检查是否含'、"、;、--、#、UNION、SELECT、EXEC（忽略大小写） - 对JSON Body，必须用
Flux<DataBuffer>异步读取后解析为JsonNode，再遍历所有字符串字段——直接objectMapper.readValue(jsonStr, Map.class)会跳过类型校验，留出漏洞 -
timestamp参数必须存在、为long类型、与当前时间差≤300000ms；nonce长度≥8且需Redis缓存去重；签名原文必须包含二者并排序拼接，否则攻击者可固定nonce反复修改timestamp绕过 - 命中规则时返回
400 Bad Request，记录原始参数用于溯源，不抛异常、不打印堆栈，防止泄露表名或数据库版本
支付回调等高危接口必须字段级白名单校验
微信/支付宝回调接口是重灾区，验签通过 ≠ 参数可信。攻击者拿到appSecret后可重放+篡改，out_trade_no里塞ORDER-123'; DROP TABLE orders;--就能触发执行。
-
out_trade_no必须匹配正则^[a-zA-Z0-9_-]{8,64}$，显式禁止.、%、'、"、;、--、/* -
total_amount必须是严格两位小数字符串，用number_format(floatval($amount), 2, '.', '')标准化后再比对原始值，防99.999或+99.99触发浮点解析漏洞 -
trade_status只接受TRADE_SUCCESS、TRADE_CLOSED等固定枚举，禁用任何空格、换行、Unicode零宽字符 - 微信
resource.ciphertext解密后仍是JSON字符串，必须用jsonNode.get("resource").get("original_type").asText()取值，不能map.get("out_trade_no")直取
数据库层执行前必须切断所有字符串拼接路径
参数化查询不是“用了就行”，而是每一条WHERE、ORDER BY、LIMIT后的值都必须走占位符；动态列名/表名若真无法避免，只能从预设枚举映射，绝不可来自任意请求参数。
- Java必须用
PreparedStatement，禁用String.format()或+拼接SQL；Python必须用cursor.execute("SELECT * FROM t WHERE id = %s", (user_id,))，禁用f"WHERE id = {user_id}" - ORM如GORM/SQLAlchemy启用
PrepareStmt=true，禁用.raw()或.execute()原生调用；Hibernate禁用@Query(value = "...", nativeQuery = true)除非绝对必要 - 数据库账号必须遵循最小权限原则：仅授予目标表的
SELECT/INSERT/UPDATE，禁用DROP、CREATE、EXECUTE；读接口字段级控制，如用户查询不返回password_hash - 所有数据库异常（MySQL 1064、PostgreSQL 42601）必须被全局异常处理器捕获，响应体只返回
"请求处理失败，请稍后重试"，原始错误只记日志，不透出表名、字段名、数据库类型
真正容易被忽略的是：网关层SQL检测和签名验证必须串联，不能独立启用；支付回调解密后那一步JsonNode遍历，比验签本身更关键；还有——所有正则校验必须用Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE，否则UnIoN或带零宽空格的SELECT能绕过。
