Spring Data JPA禁用Native Query能否完全避免SQL注入风险？

本文共计938个文字，预计阅读时间需要4分钟。

禁用不可信的 Native Query 是最有效的防线，因为 @Query(nativeQuery=true) 本身就免不了 SQL 注入——它只是把 SQL 交给了 JDBC PreparedStatement，但前提是 SQL 字符串里没有混入用户输入。

nativeQuery 为什么看起来“安全”实则危险

很多人误以为加了 nativeQuery = true 就自动防注入，其实它只保证命名参数（如 :name）走预编译绑定，但整个 SQL 字符串仍由开发者拼出来。一旦你在字符串里拼接用户输入，比如 "SELECT * FROM " + tableName + " WHERE id = :id"，JPA 根本不拦你，PreparedStatement 也救不了——因为表名根本不是参数上下文。

• 错误示例：@Query(value = "SELECT * FROM user WHERE name = '#{#name}'", nativeQuery = true) —— #{} 是 SpEL 表达式，运行时直接字符串替换，等同于拼接
• 更隐蔽的坑："SELECT * FROM user WHERE status IN (" + String.join(",", ids) + ")" —— 即使 ids 是数字列表，未经校验的字符串拼接仍可能被注入 1,2,3) OR (1=1
• PostgreSQL 的 quote_ident() 在 JPA 中无效：JPA 不解析函数语义，:table 传进去仍是纯字符串，不会触发数据库端转义

哪些 nativeQuery 场景必须人工白名单校验

动态表名、列名、排序方向（ASC/DESC）、GROUP BY 字段、UNION 分支，这些都属于 SQL 结构部分，不能靠参数化。JPA 规范明确禁止运行时解析它们。

• 表名/列名：必须从预设集合中匹配，例如 Set.of("user", "order", "product")，不匹配就抛 IllegalArgumentException
• 排序字段：只允许 "created_at", "updated_at", "score" 等硬编码值，禁止接收 request.getParameter("sort") 直接进 SQL
• IN 子句：别写 WHERE id IN :ids（JPA 不支持数组展开），改用构建固定长度占位符，如 WHERE id IN (?, ?, ?)，再用 PreparedStatement.setLong(i, id) 逐个绑定

替代方案：什么时候该放弃 @Query(nativeQuery = true)

当你的查询需要真正动态的结构（比如多租户分表、按业务类型切换主表、实时字段聚合），@Query 已经不是合适工具。继续硬塞只会让校验逻辑越来越重、出错概率越来越高。

• 改用 JdbcTemplate + 白名单 + PreparedStatement：你能完全控制 SQL 拼接时机和校验点，比如先 validateTableName(inputTable) 再 query("SELECT * FROM " + safeTable + " WHERE ...", stmt -> { ... })
• 复杂条件组合优先走 Specification：它生成的是 JPQL，底层由 Hibernate 转成安全的预编译 SQL，连 LIKE 通配符都建议写死在语句里（LIKE %:name%），而非由 Java 拼 "%" + name + "%"
• 真要执行不可控 SQL（如后台 DBA 工具）：必须限制数据库账号权限（只读、禁用 DROP/EXECUTE）、记录完整执行日志、设置超时阈值

最麻烦的不是写不出安全代码，而是有人在 Service 层偷偷用 String.format 拼完 SQL 再扔给 JdbcTemplate，还自以为“没用 @Query 就没事”。这种绕过框架约束的手动拼接，才是生产环境里最常被漏掉的注入入口。