使用StringBuilder构造JPA原生查询的风险及安全性问询

首先明确一点：StringBuilder本身只是个字符串拼接工具，它本身不会导致SQL注入——危险的是你拼接SQL的方式，尤其是处理用户可控参数的时候。

直接拼接参数的风险：确实可能被注入，甚至删库 #

如果你直接把用户输入的参数（比如前端传的筛选条件、用户ID之类的）用append拼进SQL字符串里，那绝对是高危操作。举个极端例子：
假设你要查某个用户的信息，代码写成这样：

String userId = userInput; // 用户输入的内容，比如 "'; DROP TABLE users; --"
StringBuilder sql = new StringBuilder("SELECT * FROM users WHERE id = ").append(userId);
Query query = entityManager.createNativeQuery(sql.toString());

这时候执行的SQL会变成：

SELECT * FROM users WHERE id = ''; DROP TABLE users; --

数据库会先执行查询，然后执行DROP TABLE users，直接把表删了——这种注入是完全可能的，只要攻击者构造出恶意的参数。

正确的做法：始终用参数绑定，不管用不用StringBuilder #

不管你的SQL有多复杂，需要多少条件判断和循环拼接，永远不要把参数值直接拼进SQL字符串。JPA的原生查询支持参数绑定，两种方式：

1. 位置参数：用?占位，然后用setParameter按位置设置值
2. 命名参数：用:paramName占位，然后用setParameter("paramName", value)设置值

比如复杂场景的例子：

StringBuilder sql = new StringBuilder("SELECT * FROM orders WHERE 1=1");
List<Long> statusList = getFilterStatus(); // 从业务逻辑来的筛选状态
if (!statusList.isEmpty()) {
    sql.append(" AND status IN (:statuses)");
}
String keyword = getSearchKeyword(); // 用户输入的搜索关键词
if (keyword != null && !keyword.isBlank()) {
    sql.append(" AND (order_no LIKE :keyword OR customer_name LIKE :keyword)");
}

Query query = entityManager.createNativeQuery(sql.toString());
if (!statusList.isEmpty()) {
    query.setParameter("statuses", statusList);
}
if (keyword != null && !keyword.isBlank()) {
    query.setParameter("keyword", "%" + keyword + "%");
}

这种方式下，所有用户可控的参数都是通过setParameter传入的，JPA会自动处理参数的转义，攻击者的恶意输入会被当作普通字符串处理，不会被解析为SQL命令，自然也就避免了注入风险，包括删库这种操作。

关于命名查询的补充 #

你提到知道命名查询更安全，但场景不允许用——其实只要坚持参数绑定的原则，用StringBuilder拼接SQL的结构（比如条件分支、动态的JOIN之类的）是完全没问题的。命名查询的优势是SQL更集中、易维护，但动态拼接SQL只要参数处理得当，安全性和命名查询是一样的。

总结 #

• StringBuilder本身是安全的，它只是帮你拼接SQL的结构，不会引入注入风险；
• 风险完全来自于直接将用户可控的参数值拼入SQL字符串；
• 只要所有参数都通过JPA的setParameter方法绑定，不管你的SQL有多复杂，都能有效避免SQL注入，包括恶意删库的操作。

内容的提问来源于stack exchange，提问作者Octtavius