动态表名不能参数化是数据库语法硬限制，因编译期需确定对象结构，变量仅运行时存在；必须通过白名单校验+QUOTENAME()封装双重防护，缺一不可。

动态表名为什么不能参数化

数据库引擎根本不允许在FROM、JOIN或INSERT INTO后面用@tablename这类占位符——这不是写法问题，是语法层级的硬限制。你一试就会收到类似Incorrect syntax near '@'或ORA-00903: invalid table name的报错。参数化只保护“值”，不保护“结构”。把表名塞进sp_executesql的参数列表里，SQL Server会直接拒绝执行。

白名单必须硬编码在代码里，不能从配置读

很多人以为“配置表由管理员维护，所以可信”，但低权限攻击者只要拿到一个后台 XSS 或弱口令，就能篡改log_table_name字段，让应用拼出logs; DROP TABLE users --。白名单校验动作必须落在 SQL 构造之前，且不可被运行时绕过：

• allowed_tables = ["user_events", "order_logs", "pay_records"]——必须是字面量列表，不是从 DB/Redis/配置中心加载
• 校验失败立即抛IllegalArgumentException或ValueError，绝不进入 DAO 层
• 正则兜底要严格：^[a-z][a-z0-9_]{2,31}$（小写字母开头、3–32 字符、仅字母数字下划线）

MyBatis 里 ${} 不是“用了再说”，是高危信号

${} 是纯字符串替换，MyBatis 完全不介入预编译，#{} 对它毫无约束力。典型危险写法：

SELECT * FROM ${config.tableName} WHERE id = #{id}

这里#{id}安全，但${config.tableName}已失守。修复路径只有一条：

• Java 层先查白名单字典：safeTable = tableMap.get(userInput)
• 查不到就拒掉，不往下传
• 最后用String.format("SELECT * FROM %s WHERE id = ?", safeTable)拼接——拼的只是已确认合法的字符串

SQL Server 存储过程中拼表名，QUOTENAME() 不够用

QUOTENAME(@table_name)能防users]; DROP TABLE admins--这类闭合攻击，但它不校验语义合法性。攻击者传sys.tables或##temp，QUOTENAME照单全收。真正安全的做法是三段式：

• 先用白名单映射：CASE @input WHEN 'orders_2024' THEN 'orders_q1' ELSE THROW 50000, 'Invalid table', 1 END
• 再用QUOTENAME()封装映射后的结果
• 最后进sp_executesql模板：SELECT * FROM ' + @safe_quoted_name + ' WHERE ...

漏掉任何一段，都等于把门虚掩着。白名单校验必须在QUOTENAME之前，否则后者只是给恶意输入套了个安全壳。