白名单过滤不能单独防御sql注入，必须与参数化查询配合使用；它仅校验输入格式合法性，不阻止拼接执行，需在入口处严格校验如user_id、status等固定取值字段，并避免正则不完整、校验绕过、多字节处理不当等常见错误。
白名单过滤本身不能防SQL注入，但它在参数化查询之外，是唯一能提前拦住非法输入结构、降低后续处理风险的补充手段。
白名单为什么必须配合参数化查询才有效
白名单只校验“输入像不像合法数据”，不干预“这个数据会不会被拼进SQL里执行”。如果代码里还存在 WHERE name = ' + name + ' 这类字符串拼接，哪怕 name 已通过 ^[a-zA-Z0-9_]{3,20}$ 校验，攻击者仍可输入 id DESC, (SELECT password FROM users LIMIT 1) 来破坏 ORDER BY 子句逻辑。
真正起作用的链路是：白名单在应用入口做第一道筛子 → 参数化查询在数据库访问层做最终隔离。两者不在同一层，也不互相替代。
- 白名单失败时，应直接返回
400 Bad Request，不进入业务逻辑 - 参数化查询必须覆盖所有动态拼接点，包括
ORDER BY、LIMIT、表名/列名等无法用?占位的场景 - ORM 框架（如 MyBatis 的
<bind></bind>或 Hibernate 的@Filter）若开启原生 SQL 模式，白名单就得补上那一环
哪些字段适合加白名单校验
白名单真正有用的地方，在于业务语义明确、取值范围固定的字段。这类校验能提前拦截明显异常输入，也便于日志归因。
-
user_id：只接受正整数，拒绝负数、小数、空字符串 -
status：只允许预设枚举值，如"active"、"inactive"、"pending" -
phone：用正则匹配标准手机号格式（如^1[3-9]\d{9}$），不接受含单引号、分号、反斜杠等SQL元字符 -
username：限制为字母、数字、下划线，长度 3–20，拒绝空格和控制字符
白名单实现时最容易踩的三个坑
规则太松、校验位置错、没覆盖所有入口——这三类问题在真实项目中高频出现。
- 用正则写
[a-zA-Z0-9_]却忘了加^和$，导致admin'--这种输入也能部分匹配通过 - 只在校验层做了白名单，但 API 接口、管理后台、定时任务等其他调用路径绕过了校验
- 对多字节字符（如中文、emoji）处理不当，正则未启用
u标志，导致截断或误判 - 把白名单逻辑写在前端 JavaScript 里，后端完全不校验——攻击者直接发请求就能跳过
最常被忽略的动态排序和分页参数
sort_by 和 order 这类参数没法用 ? 占位，只能靠白名单硬校验。漏掉这里，等于给注入留了后门。
正确做法不是校验用户输入是否“看起来干净”，而是映射到预定义枚举值：
const sortMap = {
'name': 'user_name',
'time': 'created_at',
'score': 'rating'
};
const dbField = sortMap[req.query.sort_by] || 'created_at'; // 只取映射结果
同理，ORDER BY 后只能拼 dbField + ' ' + (req.query.order === 'desc' ? 'DESC' : 'ASC')，而不是直接拼接原始输入。
动态表名、列名、复杂搜索表达式这些场景，白名单也得按业务语义建模，不能依赖通用正则。脱离上下文的“通用白名单”反而可能误杀合法输入，比如邮箱里的 @、中文用户名。
