在Java中如何使用注解（Annotation）防范SQL注入？-SQL-PHP中文网

mybatis的@select和@insert注解本身不防sql注入，关键在于使用#{}进行预编译参数化，而${}会导致字符串拼接引发注入；spring data jpa的@query注解在nativequery=true时参数绑定失效，原生sql应改用jdbctemplate配合preparedstatement；自定义注解无法替代参数化，白名单校验和最小权限原则才是有效防线。

在java中如何使用注解（annotation）防范sql注入？

MyBatis里`@Select`和`@Insert`注解本身不防注入，关键看怎么用

很多人看到@Select("SELECT * FROM user WHERE name = #{name}")就以为“用了注解=安全”，这是危险的错觉。MyBatis的#{}才是参数化执行的核心，而@Select只是把SQL写在注解里——它不改变SQL解析逻辑，也不自动校验输入。

真正起作用的是占位符语法：#{}触发预编译，${}直接字符串替换。只要混用${}，哪怕写在@Select里也立刻失守。

@Select("SELECT * FROM ${tableName} WHERE id = #{id}") —— ${tableName}是高危拼接，表名不能由用户控制
@Select("SELECT * FROM user WHERE name LIKE '%${keyword}%'") —— ${keyword}让模糊查询变成注入入口
@Select("SELECT * FROM user ORDER BY ${sortField} ${sortOrder}") —— 排序字段和方向必须走白名单校验，不能直通${}

Spring Data JPA的`@Query`注解必须配`nativeQuery = false`才启用参数绑定

@Query默认走JPQL（非原生SQL），此时:param或?1能安全绑定；但一旦设nativeQuery = true，就退化为原始JDBC执行，参数绑定机制失效，除非你手动用PreparedStatement——而注解层根本做不到。

常见错误：

@Query(value = "SELECT * FROM users WHERE email = ?1", nativeQuery = true) —— 看似安全，但?1在原生SQL中不保证预编译，取决于驱动实现，MySQL Connector/J 8.0+ 才默认开启服务器端预编译，旧版本可能回退到客户端拼接
@Query(value = "SELECT * FROM users WHERE status = :status AND created_at > :date", nativeQuery = true) —— 命名参数在nativeQuery = true下多数场景被当作字符串插值，不是真正的参数化

正确做法：原生SQL必须用@Query + nativeQuery = false（即JPQL）；若真需原生SQL，改用JdbcTemplate配合PreparedStatement，别依赖注解“自动防护”。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

自定义注解如`@SqlSafe`无法替代参数化，只能做辅助校验

有人试图写个@SqlSafe注解加AOP拦截，在DAO方法入参时做正则过滤。这看似主动，实则问题一堆：

校验规则难覆盖全：比如手机号正则^[1-9]\d{10}$拦不住12345678901' OR '1'='1这种绕过变体
误杀合法输入：邮箱user@domain.co.uk含点号和连字符，简单黑名单会干掉
漏掉非String类型：Long userId参数被parseInt()失败后抛NumberFormatException，但攻击者可传99999999999999999999触发溢出或数据库超时，这不属于SQL注入，但属于输入失控

真正有效的前置校验，是结合业务语义的白名单，比如分页参数只允许pageNum ∈ [1, 1000]、pageSize ∈ [1, 100]，而不是靠注解“扫描字符串”。

注解不是防火墙，`PreparedStatement`才是唯一可信的边界

所有框架注解最终都编译成JDBC调用。MyBatis的#{}、JPA的:param、Spring JDBC的update(String sql, Object... args)，底层无一例外调用PreparedStatement.setXXX()。没有这个调用，就没有真正的隔离。

容易被忽略的点：

MyBatis动态SQL里的<if test="order != null">ORDER BY ${order}</if> —— ${}在XML里同样危险，和注解里没区别
日志配置开show_sql=true，会把带参数值的完整SQL打出来，等于把脱敏后的数据又“明文曝光”，和注入无关，但属典型信息泄露
数据库账号权限没收缩，即使SQL安全，攻击者拿到SELECT权限后仍可扫表；DROP权限开着，一条注入就能删库

注解只是语法糖，别把它当盾牌。盯住PreparedStatement是否被真实调用，比研究注解写法重要十倍。