SQL注入防护单元测试应验证防护逻辑是否在关键路径生效，重点测恶意输入拦截、参数化查询调用、错误信息不泄露；须用真实输入触发SQL构建，避免绕过解析层或测试假防护。
SQL注入防护单元测试该测什么
不是测“系统有没有被黑”，而是测你写的防护逻辑是否在关键路径上真正起效。重点验证三类行为：输入含 ' OR 1=1-- 这类恶意片段时，是否被拦截或安全转义；参数化查询是否被正确调用；以及错误信息是否泄露数据库结构（比如抛出 MySQLSyntaxErrorException 或 PSQLException）。
常见错误现象：测试只 mock 了 DAO 层返回值，却没传真实恶意字符串进 service 方法；或者用 PreparedStatement 构造 SQL 但拼接了用户输入——这种写法本身已违规，测试却通过，属于“测了假防护”。
- 必须用真实输入字符串触发实际 SQL 构建逻辑（哪怕底层是 MyBatis 或 JPA），不能绕过解析层
- 对使用
String.format、+拼接 SQL 的旧代码，测试要能捕获运行时异常或非法查询日志 - 若用 Hibernate，需确认
@Param注解或TypedQuery参数绑定方式，而非createNativeQuery+ 字符串拼接
JUnit 5 中模拟恶意输入并验证异常路径
直接传 "admin'--" 进登录方法，看是否抛出预期的业务异常（如 IllegalArgumentException），而不是数据库异常。这说明你的校验层（如正则过滤、白名单检查）生效了；如果抛出 SQLException，说明防护没拦住，已进入 DB 执行阶段。
示例（Spring Boot + JUnit 5）：
@Test
void whenUsernameContainsSqlComment_thenThrowsIllegalArgumentException() {
String malicious = "admin'--";
assertThatThrownBy(() -> userService.findByUsername(malicious))
.isInstanceOf(IllegalArgumentException.class)
.hasMessageContaining("invalid characters");
}注意：不要 assert “不抛异常”，而要 assert “抛指定异常”。因为很多框架默认允许单引号，仅靠数据库驱动的语法校验不可靠，且不同方言响应不一致（PostgreSQL 可能静默截断，MySQL 直接报错）。
- 避免用
@Sql或内存数据库执行真实 SQL——那测的是 DB 防御能力，不是你的代码 - 若业务逻辑中调用了
Statement.executeQuery，测试必须覆盖该分支，并验证其输入是否经PreparedStatement包装 - 对前端传来的 JSON，测试应包含 raw body 含
\u0027（URL 编码单引号）等变体，确认解码后仍被拦截
MyBatis 场景下验证 #{} 与 ${} 的使用是否合规
#{} 是安全的占位符，${} 是字符串替换，后者等于把门打开。单元测试必须明确识别并拒绝任何含 ${} 的动态 SQL 使用，尤其在 order by、表名、字段名等无法参数化的场景。
实操建议：
- 在测试资源目录放一个扫描脚本（如 Python 或 Shell），遍历所有
*.xml文件 grep\$\{，失败时 fail build——这不是单元测试，但必须和 UT 同步执行 - 对使用
${tableName}的 mapper 方法，写测试强制传入"users; DROP TABLE users--"，验证是否抛出RuntimeException或被中间件（如 ShardingSphere）拦截 - MyBatis-Plus 的
QueryWrapper若调用eq("name", userProvidedValue)是安全的；但若用apply("name = {0}", userInput)就等同于${}，测试需覆盖该 case
容易被忽略的边界：ORM 懒加载 + HQL 注入
JPA/Hibernate 的 @Query 如果拼接了用户输入，即使用了 ? 占位符，也可能因懒加载触发二次查询而暴露漏洞。例如：用户传入 "1 or 1=1" 作为 ID，service 返回实体后，前端调用 user.getOrders().size() 触发 SELECT * FROM orders WHERE user_id = 1 or 1=1。
这类问题不会在单个 DAO 测试里暴露，必须构造完整链路：
- 测试方法需调用 service 层返回实体，再访问其关联集合属性，观察生成的 SQL 是否含原始输入
- 启用
spring.jpa.show-sql=true并捕获org.hibernate.SQL日志，断言 SQL 字符串不含用户输入原文 - 对
@Query(value = "SELECT * FROM users WHERE id = ?1", nativeQuery = true)，?1 必须是 Long/Integer 类型，若传 String 且未校验格式，可能绕过类型转换直接拼入 SQL
最麻烦的不是写测试，是让团队接受：所有接收外部输入的入口点，都得有对应 UT 覆盖恶意字符串。漏掉一个 PathVariable 或 RequestParam，整套防护就形同虚设。
