在Spring Boot 3中动态拼接SQL语句为何会导致严重安全漏洞？

作者：袖梨 2026-07-02

SQL注入漏洞源于用户输入参与SQL字符串拼接，而非参数化绑定；MyBatis的${}、QueryWrapper的apply()/last()、JPA的@Query拼接等均会绕过PreparedStatement防护，必须对动态字段做白名单校验。

因为数据库只认字符串，不认“意图”——你拼出来的那条SQL，攻击者能直接改写成另一条。

动态拼接 SQL 本质是把用户输入当代码执行

Spring Boot 3 本身不生成 SQL，但开发者用 String.format()、+ 拼接、或 MyBatis 的 ${} 语法时，就等于把用户输入原封不动塞进 SQL 字符串里。数据库收到的不是“查用户名为 XXX 的用户”，而是一整段待解析的文本——攻击者只要让这段文本变成 SELECT * FROM users WHERE username = 'admin' OR '1'='1'，查询条件就彻底失效。

常见错误写法：@Select("SELECT * FROM users WHERE name = '${name}'")（MyBatis 注解中用 ${}）
危险场景：模糊搜索、动态排序、多条件组合查询
后果不是报错，而是静默返回不该看的数据，甚至执行 DROP TABLE

MyBatis-Plus 的 `QueryWrapper` 并不自动免疫注入

很多人误以为用了 QueryWrapper 就绝对安全，其实它只是封装了参数绑定逻辑——一旦你混用 apply() 或 last() 方法插入原始 SQL 片段，就立刻退回到拼接模式。

queryWrapper.eq("name", name) ✅ 安全（底层走 PreparedStatement）
queryWrapper.apply("age > " + userAge) ❌ 危险（userAge 是用户传入的字符串）
queryWrapper.last("ORDER BY " + sortField) ❌ 危险（sortField 若未白名单校验，可填 id; DROP TABLE users--）

JPA 的 `@Query` 注解也分“编译期”和“运行期”

@Query 默认使用命名参数（:name），这是安全的；但若你用 nativeQuery = true 且里面写了 WHERE name = ?1，再配合 String.valueOf() 拼接传参，等于绕过所有框架保护。

安全写法：@Query("SELECT * FROM users WHERE name = :name")
高危写法：@Query(value = "SELECT * FROM users WHERE name = ?1", nativeQuery = true) + repository.findByName("' OR 1=1 --")
更隐蔽的坑：@Query 中用 CONCAT('%', :keyword, '%') 做模糊查询没问题，但若写成 "%"+ keyword +"%" 再拼进 SQL 字符串，就崩了

真正防住的关键不是“用哪个框架”，而是“谁在构造最终 SQL 字符串”

Spring Boot 3 的 JDBC 层、MyBatis、JPA 都依赖 PreparedStatement，但它只在参数值被单独传入时才生效。只要你让用户输入参与了 SQL 字符串的拼接过程，哪怕只拼了一个字段名、一个表名、一个 ORDER BY 子句，防御就已失效。

表名、列名、排序方向等无法用参数化，必须做白名单校验（如 sortField 只允许 "id"、"name"、"created_at"）
动态 IN 查询不能靠拼 ? 占位符个数，要用 Collection 参数配合 IN :ids
日志里看到 Preparing: SELECT * FROM users WHERE name = ? 才算真正进入预编译流程；如果日志里是 Preparing: SELECT * FROM users WHERE name = 'admin''--'，已经中招