JSON字段值可触发SQL注入，因后端若将解析后的字符串直接拼入SQL（如"WHERE id = " + data["user_id"]），攻击者提交{"user_id": "1 OR 1=1"}即可执行恶意查询；JSON仅是传输格式，非安全边界，参数化查询才是唯一有效防护。
JSON接口本身不执行SQL，但只要后端把解析出来的字段值直接拼进SQL语句，风险就和表单参数一模一样——name、email、id这些字段值，和URL里的id=1没有本质区别。
为什么JSON字段值也能触发SQL注入
攻击者根本不需要懂前端或API设计，只看后端是否“信任字符串”。比如收到一个{"user_id": "1 OR 1=1"}，如果代码里写的是：
sql = "SELECT * FROM users WHERE id = " + data["user_id"]
那数据库收到的就是SELECT * FROM users WHERE id = 1 OR 1=1，全表泄露。关键点在于：JSON只是传输格式，不是安全边界。
- JSON解析后得到的是普通字典/对象，字段值仍是原始字符串，没做任何过滤
- 后端若用字符串拼接构造SQL（哪怕只拼一个
WHERE条件），就等于开门揖盗 - 攻击载荷可以藏在任意字段：
username、filter、sort_by、甚至metadata这种看似“只读”的字段
JSON Schema校验不能代替参数化查询
很多人以为加了JSON Schema就能防注入，其实它只管结构和类型，不管内容安全性。比如这个schema：
{
"type": "object",
"properties": {
"name": {"type": "string", "maxLength": 50},
"age": {"type": "integer"}
}
}
它允许"name": "admin' --"通过验证——因为这是合法字符串，长度也没超。Schema能拦住{}或null，但拦不住'、;、--这些SQL元字符。
-
JSON Schema是数据契约，不是安全过滤器 - 它无法识别
"1; DROP TABLE logs;"这种字符串的恶意意图 - 绕过方式极简单：用
UNION SELECT、IF(1=1, SLEEP(5), 0)等不依赖特殊字符的盲注手法
真正有效的JSON字段防护动作
核心原则只有一条：所有从json.loads()（或等价解析）拿到的值，进SQL前必须走参数化路径，不能出现在SQL字符串里。
- Python用
cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])，别用%格式化 - Node.js用
pool.query("SELECT * FROM t WHERE name = $1", [name])（PostgreSQL）或?占位符（MySQL） - Java用
PreparedStatement，字段名/表名这类动态部分需白名单校验，不能参数化 - 对
ORDER BY、GROUP BY等无法参数化的上下文，必须严格限制为预设枚举值，例如["created_at", "score"]
容易被忽略的JSON注入盲区
开发者常盯着body，却漏掉其他入口。以下位置同样危险，且更难被测试覆盖：
-
X-Forwarded-For头里塞127.0.0.1' UNION SELECT password FROM users--，如果日志模块把它当字符串写进SQL - JWT
payload中的sub或scope字段，未经清洗就用于权限查询 - Webhook回调里带的
event.data.id，直接拼进UPDATE events SET processed = 1 WHERE id = ... - 前端传来的
{"filters": {"status": "active' OR '1'='1"}}，后端递归拼接WHERE条件时没做隔离
JSON不是银弹，它只是让输入点更隐蔽。真正的防线永远在SQL执行那一刻——你是否把数据当数据，还是当代码的一部分来对待。
