createQuery()本身不防注入，仅解析HQL字符串；安全依赖setParameter()触发PreparedStatement机制，命名参数须严格匹配，表名/字段名等动态部分需白名单校验，推荐用Criteria API彻底规避注入。
createQuery() 本身不防注入，只负责解析字符串
很多人误以为只要用了 createQuery() 就自动安全了，其实它只是把传入的字符串当作 HQL 模板去语法解析，不做任何参数校验或值替换。哪怕你写了 "FROM User WHERE name = :name"，如果后续没调用 setParameter()，Hibernate 也不会报错——直到执行时才抛 QueryParameterException，功能直接中断。
真正起防护作用的是 JDBC 层的 PreparedStatement 绑定机制，而 Hibernate 只有在你显式调用 setParameter() 后才会触发它。
- ❌ 危险写法：
session.createQuery("FROM User WHERE name = '" + userInput + "'") - ✅ 安全写法：
session.createQuery("FROM User WHERE name = :name").setParameter("name", userInput) - ⚠️ 伪安全写法：
session.createQuery("FROM User WHERE name = :name")（漏掉setParameter）→ 运行时报错，不是注入但逻辑失效
命名参数必须严格匹配且显式绑定
:name 在 HQL 中只是占位符声明，不是安全开关。参数名大小写敏感、拼写必须完全一致，否则 setParameter() 找不到对应位置，照样报错。
推荐统一用 setParameter()，Hibernate 5.2+ 已废弃 setString() 等类型后缀方法：
- ✅ 推荐：
query.setParameter("userName", username)（自动推导类型） - ✅ 显式类型：
query.setParameter("age", 25, StandardBasicTypes.INTEGER) - ❌ 过时：
query.setString("username", username)（类型推导弱，枚举/自定义类型易出错） - ⚠️ 常见坑：HQL 写
:userName却传"username"→ 直接QueryParameterException
动态字段、表名、排序方向不能参数化，必须白名单校验
HQL 和原生 SQL 都不支持把表名、字段名、ASC/DESC 当作参数绑定。下面这些写法全是非法的，且极易引入注入：
- ❌
session.createQuery("FROM " + tableName + " WHERE id = :id") - ❌
session.createQuery("ORDER BY " + sortField + " " + sortOrder) - ❌
session.createQuery("WHERE status IN (" + idsStr + ")")
正确做法是提前定义可接受的值集合，并做运行时校验：
- 表/字段白名单：
if (!Set.of("user", "order", "product").contains(fieldName)) throw new IllegalArgumentException(); - 排序方向限制：
sortOrder = "ASC".equals(sortOrder) ? "ASC" : "DESC" - IN 列表用
setParameterList("ids", idList)，不要手动拼(?, ?, ?)
优先用 Criteria API，从源头杜绝字符串拼接
Criteria API 是唯一能彻底规避 HQL 注入的方式——整个查询结构由 Java 方法链构建，字段名是实体属性名，受编译器检查，拼错直接编译失败。
示例：
CriteriaBuilder cb = session.getCriteriaBuilder();
CriteriaQuery<User> cq = cb.createQuery(User.class);
Root<User> root = cq.from(User.class);
cq.select(root).where(cb.equal(root.get("username"), username));
List<User> users = session.createQuery(cq).getResultList();
注意点：
- 字段名
"username"是 Java 属性名，不是数据库列名，拼错编译不过 - 值仍需传变量，但已脱离 SQL 文本上下文，不可能被解释为代码
- 复杂函数（如
GROUP_CONCAT）、深度嵌套子查询等场景，仍需回退到 HQL + 严格参数绑定
动态条件组装、排序字段、分页 offset/limit 这些地方最容易漏检，也是实际项目中最常被攻破的入口。别只盯着主查询，要逐行审查所有字符串拼接点。
