白名单校验不能单独防sql注入，因其仅过滤输入格式，若后续仍用字符串拼接sql，攻击者可用合法字符如admin' or '1'='1绕过；必须配合参数化查询才有效。
白名单校验为什么不能单独防SQL注入
白名单校验本身不防SQL注入，它只是在数据进入数据库前做一层格式过滤。如果后续仍用字符串拼接构造SQL，哪怕输入全是字母数字，攻击者也能通过admin' OR '1'='1这类合法字符组合绕过白名单、破坏语句逻辑。所以白名单不是“防注入”，而是“减少脏数据流入”，必须配合参数化查询才起作用。
哪些字段适合加白名单校验
白名单真正有用的地方，在于业务语义明确、取值范围固定的字段。这类校验能提前拦截明显异常输入，降低后续处理负担，也便于日志归因。
-
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 里，后端完全不校验——攻击者直接发请求就能跳过
白名单 + 参数化查询才是完整链路
真正可靠的防御，是白名单在应用层做第一道过滤，参数化查询在数据访问层做最终隔离。两者不在同一层，也不互相替代。
- 白名单失败时，应直接返回
400 Bad Request，不进入业务逻辑 - 参数化查询必须覆盖所有动态拼接点，包括
ORDER BY、LIMIT、表名/列名等无法参数化的场景，得用白名单硬校验 - ORM 框架（如 MyBatis 的
<bind></bind>或 Hibernate 的@Filter）若开启原生 SQL 模式，白名单就得补上那一环
最常被忽略的是动态排序和分页参数——它们没法用 ? 占位，只能靠白名单严格限定为 "created_at"、"desc" 这类固定值。漏掉这里，等于给注入留了后门。
