如何解决Spring Data JPA中的SQL注入问题_利用Query注解的命名参数

如何解决Spring Data JPA中的SQL注入问题：利用Query注解的命名参数

Query注解里用字符串拼接就是SQL注入温床

在 @Query 注解的 JPQL 或原生 SQL 字符串里，直接用 + 号拼接用户输入，这无异于把数据库的钥匙直接交给了请求参数。虽然 JPQL 不支持将预编译占位符（比如 ?1）与动态字段名或表名混合使用，但命名参数（:name）本身是安全的——前提是，别用它去拼接 SQL 语句的结构部分。

命名参数只能绑定值，不能绑定列名或表名

这里有个最常见的误区：以为写了 @Query("SELECT * FROM :table WHERE name = :name") 就算用了命名参数。实际上，:table 会被当作一个普通的字面量字符串处理，而不是进行参数替换，运行时要么直接报错，要么查不到任何数据。JPA 规范明确禁止在运行时解析动态的表名或列名。

• :param 只能出现在 WHERE、HA VING、ORDER BY（值部分）、GROUP BY（值部分）这类**值上下文**中。
• 表名、列名、函数名、排序方向（ASC/DESC）这些结构部分，必须硬编码在 SQL 里，或者经过外部严格校验后，通过白名单机制进行拼接。
• 如果业务上确实需要动态表名，建议改用 JdbcTemplate 配合白名单校验和 PreparedStatement，别强行塞进 @Query 里。

安全写法：命名参数 + 严格类型约束 + 白名单兜底

下面这个例子看起来平平无奇，但每一步其实都在为安全加锁：

@Query("SELECT u FROM User u WHERE u.status = :status AND u.name LIKE %:name%")
List findUsers(@Param("status") Integer status, @Param("name") String name);

• status 参数是 Integer 类型，JPA 底层会自动将其转换为 JDBC 的 setInt() 调用，从根本上杜绝了字符串逃逸的可能。
• name 参数虽然是 String 类型，但它只用于 LIKE 右侧的模糊匹配，而且通配符 % 是直接写死在 SQL 语句里的，并非从参数中拼接进来。
• 如果业务要求按多个状态进行筛选，千万别写成 "status IN :statuses"（JPA 不支持直接将数组参数展开到 IN 子句中）。正确的做法是，动态构建 IN 子句，并配合一个经过白名单校验的枚举值列表。

原生 SQL 下命名参数仍安全，但得避开 CONCAT 和字符串函数

当使用 @Query(nativeQuery = true) 切换到原生 SQL 时，命名参数依然会走 JDBC 的预编译机制，安全性有保障。但需要注意的是，某些数据库函数可能会绕过参数化机制，带来隐患：

• 避免使用 CONCAT(:a, :b) 或 :col = :val 这类将参数当作标识符来用的写法。
• 像 PostgreSQL 的 quote_ident(:table) 函数，看起来能安全处理标识符，但 JPA 本身并不识别这个函数，传进去的仍然是一个未经转义的字符串。
• 真正需要动态字段时，稳妥的做法是：先用工具类（如 StringUtils.replaceChars(fieldName, ".", "_")）进行基础清洗，再与预设的白名单（例如 Set.of("user_name", "created_at")）进行比对。如果不匹配，直接抛出 IllegalArgumentException 异常。

话说回来，最棘手的问题往往不在于参数怎么写，而在于团队中可能有人在 Service 层偷偷用 String.format 拼接好 SQL，再丢给 JdbcTemplate 去执行。这种代码在编译时不会报错，但只要参数里包含一个单引号或分号，就等于为攻击者敞开了大门。所以，盯紧日志里打印出的最终 SQL 语句，比任何编码规范都更管用。