Spring Data JPA防SQL注入：你的防线真的固若金汤吗？
一个核心结论先摆在这里：只要不手动拼接SQL字符串，Spring Data JPA的默认机制就能为你挡住绝大多数注入攻击。然而，一旦你启用了原生SQL查询（@Query(nativeQuery = true)）或者开始用StringBuilder组装语句，这道防线便会瞬间失效。
哪些JPA查询方式天然免疫SQL注入
Spring Data JPA的常规查询方法之所以安全，是因为它们将脏活累活都交给了底层的Hibernate。Hibernate会自动将查询转化为预编译的SQL语句（PreparedStatement），所有参数都通过占位符绑定，从根本上杜绝了字符串拼接。这意味着，在大多数情况下，你甚至无需额外操心。
- 派生查询方法：像
findByUsername(String username)或findByStatusAndRole(String status, String role)这类方法，参数会被自动、安全地绑定。 - JPQL配合命名参数：例如
@Query("SELECT u FROM User u WHERE u.email = :email")并搭配@Param("email")，Hibernate会将其解析为预编译的占位符，同样安全。 - 处理集合参数：即便是
@Query("SELECT u FROM User u WHERE u.id IN :ids")这样的IN查询，Hibernate也会智能地将集合参数展开为对应数量的“?”，安全无忧。 - 仓库自带方法：所有
JpaRepository提供的标准方法，如sa ve()、findById()，或使用Specification的复杂查询，其底层都调用标准的JPA API，不直接暴露SQL构造过程。
为什么@Query(nativeQuery = true)是高危操作
当你使用原生SQL查询时，就等于绕过了Hibernate这层“安全翻译官”，直接将SQL语句丢给了JDBC执行。如果此时还在语句中拼接用户输入的变量，无异于门户大开。
- 典型错误示范：
@Query(value = "SELECT * FROM user WHERE name = '" + name + "'", nativeQuery = true)—— 这就是一个标准的注入漏洞触发器。 - 正确做法：必须严格使用参数占位符（
?1、?2）或命名参数（:name），并通过@Param传递值。 - 一个重要限制：在原生SQL中，Hibernate不支持直接将一个集合绑定到IN子句（如
WHERE id IN :ids会报错）。遇到这种情况，通常需要改用JdbcTemplate，或者手动构造固定长度的占位符字符串。 - 安全写法示例：
@Query(value = "SELECT * FROM user WHERE status = ?1 AND dept_id IN (?2, ?3)", nativeQuery = true)，然后按位置传入三个参数。
动态条件 + 原生SQL的常见翻车点
业务中经常需要根据条件动态拼接WHERE子句。有些人会尝试用StringBuilder拼好完整的SQL字符串，再塞进@Query注解里，这是最具代表性的“自毁长城”式操作。
- 问题根源：JPA的
@Query注解内容在编译期就固定了，无法在运行时动态改变结构。所谓的“动态”，只能靠外部拼接字符串来实现，而一旦拼接，防护便宣告失效。 - 替代方案一：使用
JpaSpecificationExecutor接口配合Specification。通过类型安全的Ja va代码来动态构建查询条件，最终生成的仍然是预编译语句。 - 替代方案二：直接使用
JdbcTemplate配合PreparedStatementCreator，手动控制参数的绑定。但切记，整个过程必须严格避免任何形式的字符串插值。 - 绝对禁止的写法：
String sql = "SELECT * FROM t WHERE 1=1" + (status != null ? " AND status = '" + status + "'" : "")。
容易被忽略的“伪安全”场景
有些代码看起来用了参数化查询，但实际上仍在拼接SQL的关键结构部分，尤其是在排序、字段名、表名等非数据值的位置。
ORDER BY子句无法参数化：例如@Query("... ORDER BY :sortField")是无效的，Hibernate不允许用参数占位符来替代列名。解决方案只能是对传入的字段名进行白名单校验，或映射到有限的枚举值。- SQL结构部分不可绑定：表名、字段名、
GROUP BY、UNION等子句都属于SQL语法结构的一部分，不能使用@Param进行绑定。 - 分页排序时的风险：使用
Pageable时，如果Sort.by("user_name")中的字段名直接来自用户请求参数，必须预先校验该字段是否存在于预定义的白名单中（例如Set.of("username", "created_time")）。 - 同理可证：MyBatis-Plus的
QueryWrapper也存在类似情况：eq("username", input)是安全的，但orderByAsc(inputField)中的inputField必须经过过滤。
说到底，真正的防御核心不在于“添加了多少层校验”，而在于“是否让未经严格过滤的用户输入直接参与了SQL语句结构的生成”。哪怕只漏过一个排序字段，整个系统的安全防护就可能形同虚设。
