外部api返回值直接拼入sql语句会引发二次注入，因下游api字段可能已被污染，需在接入层过滤和业务层参数化双重防护。
外部API返回值直接拼进SQL语句会触发二次注入
你以为只校验了用户输入，但没意识到下游API返回的user_name、order_id、callback_url等字段，可能已被上游攻击者污染。一旦你用String.format("SELECT * FROM user WHERE name = '%s'", apiResp.getName())这种写法，就等于把攻击载荷原样带入第二轮SQL执行。
JSON响应里嵌套的字符串字段最容易被忽略
比如调用支付回调接口，对方返回：
{
"status": "success",
"data": {
"uid": "1001",
"remark": "test'; DROP TABLE users;--"
}
}
如果你只校验顶层status字段，再用data.remark拼SQL，漏洞立刻生效。常见错误包括：
- 只对HTTP状态码做判断，不校验响应体内容
- 用
ObjectMapper.readValue(resp, Map.class)后直接取map.get("remark")，没做任何转义或白名单过滤 - ORM框架里用
@Query("SELECT * FROM log WHERE remark = '" + remark + "'")这类硬编码拼接
第三方服务签名不可信，或根本没签名
很多SaaS API（如短信平台、物流查询、身份核验）不提供请求签名，或签名只保护传输过程，不防数据篡改。攻击者可：
- 劫持你和第三方之间的通信（中间人），篡改返回的
mobile字段为' OR '1'='1 - 伪造一个假的第三方服务，返回精心构造的JSON，诱导你写入数据库
- 利用第三方API自身的SQL注入漏洞，让它的返回值自带payload（即“供应链注入”）
修复必须分两层：接入层过滤 + 业务层参数化
不能只靠后端ORM兜底。真实可行的防护是：
- 所有外部API响应，在反序列化后立即遍历所有字符串字段，用和网关层一致的规则检测：
'、"、--、UNION、SELECT等——别依赖“它应该安全” - 业务代码中禁止出现
+拼接SQL，一律改用PreparedStatement或MyBatis的#{}占位符 - 对必须存原始字符串的字段（如日志备注），入库前统一做HTML实体编码或数据库专用转义（如MySQL的
mysql_real_escape_string逻辑）
最危险的不是你没写好SQL，而是你默认信任了别人传给你的字符串——而那个“别人”，可能已经被攻破了。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
