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''--'，已经中招
最易被忽略的点：安全边界不在 Controller 层，而在 DAO 层最后一行 SQL 构造语句。哪怕你前面做了 10 层校验，只要最后那一行用了 + 或 ${}，整条链路就塌了。
