token未校验本身不直接导致sql注入，真正漏洞在于绕过鉴权后将恶意参数拼接到sql中；根治方法是禁用字符串拼接，强制使用参数化查询，并辅以网关层初筛与严格验证。
Token 参数未校验本身不会直接导致 SQL 注入——它只是身份凭证，不是 SQL 构建的输入源。真正的问题是：攻击者利用未校验的 Token 绕过鉴权后，把恶意参数（如 user_id、keyword）送进后端，而这些参数又被拼接到 SQL 中执行。
所以修复重点不在 Token 本身，而在「未校验 Token → 放行非法请求 → 后端拼接参数 → 执行恶意 SQL」这条链路上。必须切断最脆弱的一环：SQL 拼接。
为什么只校验 Token 无法防 SQL 注入
哪怕 Token 是合法且未过期的，只要后端代码存在 "WHERE id = '" + userId + "'" 这类拼接，攻击者仍可构造 userId=1' OR '1'='1 突破数据库逻辑。鉴权只解决“谁在调用”，不解决“传了什么”。
必须禁用所有字符串拼接构造 SQL 的写法
这是唯一能根除漏洞的手段。无论 Token 是否校验、是否有效，只要 SQL 构建层用了参数化查询，恶意输入就永远只是数据，不会变成代码。
- Java：强制用
PreparedStatement，占位符统一为?，调用setString()/setLong()；绝不用String.format()或+拼接 - Python（MySQL/PostgreSQL）：用
cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])；SQLite 用?占位符；严禁f"WHERE name = '{name}'" - Node.js（pg）：用
client.query("SELECT * FROM u WHERE id = $1", [id])；mysql2同理用query(sql, [params])，而非模板字符串 - MyBatis：确认只用
#{}（参数化），禁用${}（字符串拼接）；检查所有<script></script>标签和动态 SQL 是否引入变量
网关层对 Token 的校验要绑定业务参数初筛
网关不能替后端防注入，但可以配合 Token 鉴权做轻量级兜底，防止明显畸形请求触达后端：
-
Token校验必须包含时效性：timestamp参数需存在且与当前时间差 ≤ 300000ms（5 分钟），超时即拒 - 必须校验
nonce去重：长度 ≥ 8，且 Redis 缓存最近 5 分钟内已见nonce，重复即拒 - 对已通过
Token验证的请求，额外对高危字段做初筛：user_id用正则^[0-9]+$、out_trade_no用^[a-zA-Z0-9_-]{8,64}$、keyword限制长度 ≤ 200 - 拒绝含
%00、连续%%、未闭合%2的 URL 编码，这些不是正常客户端行为
修复后必须验证是否真生效
别信“加了 Token 校验就安全了”。上线前务必用真实 payload 测试：
- 发送
GET /api/order?order_id=123%27%20UNION%20SELECT%20password%20FROM%20users--，观察是否返回 400 或 500，而不是订单数据 - 用
sqlmap -u "https://api.example.com/order?order_id=123" --batch扫描，确认无注入点 - 检查日志：若某次请求
Token有效但参数含' OR '1'='1，应记录原始参数并告警——说明密钥可能泄露或客户端被劫持
真正危险的不是没校验 Token，而是校验了 Token 就以为万事大吉，继续在 DAO 层写 String sql = "SELECT * FROM user WHERE id = " + id;。这种代码，再强的网关也拦不住。
