直接在JPA中使用原生SQL查询时，很多人会习惯性地用字符串拼接来构造查询语句，比如这样写：String sql = "SELECT * FROM users WHERE id = " + userId;。这种写法极其危险，它会把用户输入的userId原封不动地拼接进SQL语句。如果恶意用户输入的是"1 OR 1=1"，最终的查询就会变成"SELECT * FROM users WHERE id = 1 OR 1=1"，导致查询出所有用户数据，这就是典型的SQL注入攻击。要防止这种风险，核心方法就是永远不要拼接用户输入，而是使用JPA提供的参数绑定机制。
SQL注入的原理与JPA原生查询的脆弱性
SQL注入的本质是攻击者能够“注入”并执行非预期的SQL代码。在JPA中，虽然我们通常使用类型安全的JPQL（Java Persistence Query Language）和Criteria API，它们底层会自动进行参数绑定，但在处理复杂查询、数据库特定函数或优化时，我们仍可能用到原生SQL（通过createNativeQuery方法）。一旦在这里放松警惕，进行字符串拼接，就为攻击者打开了大门。JPA原生查询本身并不提供自动的输入转义或验证，它的安全性完全取决于开发者的编码方式。一个被拼接的变量，无论是来自HTTP请求参数、表单提交还是外部API，都可能成为注入点。
正确的防御之道：使用参数化查询（参数位置绑定）
最有效、最根本的防止SQL注入的方法就是使用参数化查询，也称为预编译语句。在JPA原生查询中，这通过使用问号(?)后接数字索引来实现参数位置绑定。其原理是：SQL语句的模板（包含占位符?）会先被数据库引擎解析和编译，用户输入的数据随后作为“参数”单独传入。数据库会严格区分代码和数据，将参数值视为纯数据而非可执行代码，从而从根本上杜绝了注入可能。
// 危险的做法：字符串拼接 String dangerousSql = "SELECT * FROM t_order WHERE user_id = " + inputUserId; Query dangerousQuery = entityManager.createNativeQuery(dangerousSql); // 安全的做法：使用参数位置绑定 (?1, ?2 ...) String safeSql = "SELECT * FROM t_order WHERE user_id = ?1 AND status = ?2"; Query safeQuery = entityManager.createNativeQuery(safeSql); safeQuery.setParameter(1, inputUserId); // 参数索引从1开始 safeQuery.setParameter(2, "PAID"); List results = safeQuery.getResultList();
如上所示，"inputUserId"和"”PAID”"这两个值是通过"setParameter"方法独立设置的。即使"inputUserId"被恶意传入"”1‘ OR ’1‘=’1“"，JPA和数据库驱动程序也会确保它被当作一个完整的字符串值去匹配"user_id"字段，而不会破坏SQL语句结构。查询的实际执行逻辑相当于："SELECT * FROM t_order WHERE user_id = '1'' OR ''1''=''1' AND status = 'PAID'"，这通常会因为找不到匹配的记录而返回空结果，攻击失效。
参数绑定的高级用法与命名参数
除了基础的位置参数，JPA（特别是Hibernate作为提供者时）在其原生查询中也支持更易读的命名参数（:parameterName）。这能提升代码可维护性，尤其是在参数很多的复杂查询中。
// 在JPA原生查询中使用命名参数（依赖于JPA提供者支持）
String namedParamSql = "SELECT name, email FROM t_user WHERE department = :dept AND create_date > :startDate";
Query namedParamQuery = entityManager.createNativeQuery(namedParamSql);
namedParamQuery.setParameter("dept", userInputDept);
namedParamQuery.setParameter("startDate", startDateInput);需要注意的是，JPA规范本身并未强制规定所有提供者对原生查询的命名参数支持，但主流实现如Hibernate是支持的。为确保可移植性，在编写需要跨不同JPA提供者运行的代码时，使用位置参数是更稳妥的选择。无论选择哪种方式，核心原则不变：让数据通过"setParameter"方法传递。
不仅仅是WHERE子句：全面的输入净化
参数绑定完美解决了"WHERE"、"SET"、"VALUES"等子句中的数据值问题。然而，SQL注入也可能通过表名、列名或排序关键字（"ORDER BY"）发生。这些数据库对象标识符不能使用参数占位符。例如，"”SELECT * FROM ?1“"这样的语句是无效的。对于这类情况，绝对禁止使用用户输入直接拼接。必须采用严格的白名单验证策略。
// 不安全的动态表名/列名（错误示例）
String unsafeOrderBy = "SELECT * FROM t_product ORDER BY " + userInputColumn;
// 安全的做法：白名单验证
MapallowedColumns = new HashMap<>();
allowedColumns.put("price", "price");
allowedColumns.put("create_time", "create_time");
String sortColumn = allowedColumns.get(userInputColumn);
if (sortColumn == null) {
sortColumn = "create_time"; // 提供安全的默认值
}
String safeSql = "SELECT * FROM t_product ORDER BY " + sortColumn;
Query safeQuery = entityManager.createNativeQuery(safeSql);通过预先定义允许的列名映射，我们只接受在映射中存在的输入，否则就回退到一个安全的默认值。这是一种防御性编程思维，将用户输入的控制权牢牢掌握在自己手中。
深度防御：结合ORM与最小权限原则
仅依靠参数化查询可能还不够，我们需要建立深度防御体系。首先，应优先使用JPQL或Criteria API进行查询，让JPA处理对象-关系映射和安全性。其次，在数据库层面，为应用程序使用的数据库账户遵循“最小权限原则”。这个账户不应该拥有"DROP"、"ALTER"或对敏感系统表的无条件"SELECT"权限。这样即使发生注入，攻击者能造成的破坏也极其有限。最后，对所有用户输入进行严格的格式、长度和类型校验，将其视为“不可信的”。例如，如果"userId"预期是数字，那么在Java层就应尽早将其转换为"Integer"类型，非数字输入会在绑定前就被拦截。
常见误区与代码审查要点
在实践中，一些误区需要警惕。误区一：在应用层进行简单的字符串转义（如将单引号替换为两个单引号）就认为安全了。这种方法不可靠且容易遗漏，不同数据库有不同转义规则，依赖它就是埋下隐患。误区二：认为使用了存储过程就绝对安全。存储过程内部如果使用了动态SQL拼接，同样存在注入风险。误区三：忽视日志记录。注入攻击尝试是重要的安全事件，应确保SQL日志（如果开启）不会将绑定参数明文记录，以免泄露敏感信息。
在进行代码审查时，应重点关注所有出现"createNativeQuery"和"createQuery"（用于JPQL）的地方。审查的关键问题是：“这个查询中任何来自外部的部分，是否都是通过"setParameter"方法设置的？” 任何使用"+"运算符或"StringBuilder"来拼接"WHERE"、"VALUES"、"SET"等子句内容的行为，都必须立即标记并要求修改为参数化查询。
总结：将安全内化为开发习惯
防止JPA原生查询中的SQL注入，不是一个高深的技术难题，而是一个必须内化的开发习惯。其黄金法则就是：严格区分SQL代码与用户数据。SQL代码（结构）是开发者编写的静态字符串常量，而用户数据必须且只能通过"Query.setParameter()"方法传递。无论是位置参数"?1"还是命名参数":name"，它们都是建立在这条法则之上的工具。结合输入验证、最小权限和深度防御，可以构建起稳固的数据持久层安全防线。记住，安全没有捷径，从写下第一行数据库查询代码时，就要把参数化查询作为本能。
