SQL动态拼接条件不安全的核心风险是未过滤的用户输入直接嵌入SQL，易导致SQL注入；应优先使用预编译参数化查询，结构类参数须白名单校验，必要时双重过滤并禁用多语句执行。
SQL动态拼接条件本身不安全，核心风险在于**未过滤的用户输入直接嵌入SQL语句**，极易引发SQL注入攻击。只要拼接逻辑未严格区分“代码”与“数据”，就存在被绕过验证、执行恶意语句的可能。
常见高危拼接场景
以下写法看似灵活，实则危险：
-
字符串拼接+用户参数：如
"WHERE name = '" + request.getParameter("name") + "'"—— 单引号可被闭合，后续注入任意SQL -
拼接ORDER BY字段名：如
"ORDER BY " + sortField—— 攻击者传入"id; DROP TABLE users--"可能触发多语句执行（取决于驱动） - 拼接表名或列名：这些属于SQL结构元素，无法用参数化占位符，但若直接拼入用户输入，风险极高
安全替代方案优先级排序
按安全性与实用性推荐如下：
- 首选预编译参数化查询：对red">值类条件（如WHERE age > ?、IN (?, ?, ?)），全部交由JDBC/ORM的PreparedStatement处理，数据库自动转义
-
白名单校验结构类参数：对必须动态的表名、列名、排序字段，只允许从预定义白名单中选取，例如：
if (!Arrays.asList("name", "age", "create_time").contains(sortField)) throw new IllegalArgumentException(); -
使用成熟表达式引擎：如MyBatis的
若必须手动拼接，请守住三条底线
仅在极特殊场景（如复杂报表引擎）下需自行拼接，务必做到：
-
所有值一律参数化：拼接时只保留WHERE、AND、OR等逻辑关键字和占位符
?，真实值通过setString()等方法绑定 -
结构标识符双重过滤：先白名单匹配，再正则校验（如
^[a-zA-Z_][a-zA-Z0-9_]*$），禁止任何特殊字符 -
禁用多语句执行：MySQL连接串加
allowMultiQueries=false（默认false），PostgreSQL禁用;分隔多语句
不复杂但容易忽略：安全不是“加个过滤函数”就能解决，关键在明确区分“哪里是代码、哪里是数据”，并把控制权交给数据库驱动或框架本身。
