API接口本身不是SQL注入的靶子，真正漏洞源于未校验参数直传数据库、动态字段拼接或绕过ORM的原始SQL调用；JWT鉴权和请求签名仅解决身份认证与防篡改，无法阻止SQL注入；必须在数据访问层强制使用参数化查询并限制字段名白名单、禁用SQL拼接、遵循最小权限原则。
API接口本身不是SQL注入的“靶子”，而是因为设计或实现中暴露了可被利用的路径——比如未校验的参数直传数据库、动态字段拼接、或绕过ORM安全机制的原始SQL调用。加JWT鉴权和请求签名，并不能直接阻止SQL注入；它们解决的是“谁在调用”和“请求是否被篡改”，而非“输入是否安全执行”。真正堵住SQL注入，得回到数据访问层做隔离。
JWT鉴权对SQL注入防护的实际作用有限
JWT只负责身份核验和权限上下文传递，它验证的是 Authorization 请求头里的 token 是否合法、是否过期、是否由可信 issuer 签发。但一旦 token 验证通过，后续逻辑若仍使用 username = request.query_params.get("field") 拼进 SQL，攻击者照样能用合法 token 发送恶意参数。
- JWT不校验请求体（
body）或查询参数（query）的内容合法性 - 一个拥有
user:read权限的合法 token，仍可携带?id=123%20OR%201=1这类 payload - 如果后端在鉴权后不做参数白名单/类型/长度校验，JWT只是给攻击铺了一条“已认证通道”
请求签名（如 HMAC-SHA256）能防篡改，但不防注入
请求签名验证的是整条 HTTP 请求（含 method、path、headers、body）是否在传输中被中间人修改，常用于防止重放或伪造请求。但它不解析、不约束参数语义：
- 签名正确的请求，
POST /api/users的 body 里仍可以是{"name": "admin'--"} - 签名验证通过后，该字符串若被直接拼入
"SELECT * FROM users WHERE name = '" + name + "'"，注入就发生了 - 签名密钥泄露或客户端被劫持时，攻击者甚至能自己生成合法签名的恶意请求
真正防SQL注入必须落在数据访问层
所有外部输入（无论是否带JWT、是否签过名）进入数据库前，都必须走参数化路径。MyBatisPlus 的 QueryWrapper、.NET 的 SqlParameter、PHP PDO 的 prepare()、Python SQLAlchemy 的 text().bindparam() ——这些才是防线核心。
- 禁用任何形如
wrapper.eq(userInputField, value)的字段名动态传入，字段名必须来自枚举或白名单配置 - 避免
mapper.selectBySQL("SELECT * FROM user WHERE " + condition)这类自由拼接 - 对非结构化搜索场景（如全文检索），优先用 Elasticsearch 等专用引擎，而非在 SQL 中用
LIKE %...%+ 用户输入 - 数据库账号遵循最小权限原则：应用账号不应有
DROP、CREATE或跨库查询权限
JWT 和签名是信任链的起点，不是数据处理的终点。最容易被忽略的一点是：开发者常把“接口已鉴权”等同于“输入可信”，结果在 controller 层做完 token 解析，就直接把 request.json 塞进 DAO，跳过了最关键的参数净化与绑定环节。
