所有外部输入只要参与控制流、文件路径、SQL、系统命令或动态代码加载，必须白名单校验；常见被忽略点包括$_GET['sort']、$_POST['template']、$_SERVER['HTTP_ACCEPT_LANGUAGE']、$_REQUEST['action']。
PHP中哪些输入点必须做白名单校验
所有外部进入PHP脚本的数据，只要参与控制流、文件路径、SQL执行、系统命令或动态代码加载，就必须走白名单。不是“建议”，是硬性边界。
常见被忽略的输入点包括：$_GET['sort']（用于ORDER BY字段）、$_POST['template']（用于include）、$_SERVER['HTTP_ACCEPT_LANGUAGE']（用于多语言切换）、$_REQUEST['action']（用于路由分发）。
白名单不等于“过滤非法字符”，而是明确列出允许的值，其余一律拒绝。
-
in_array($input, ['list', 'detail', 'export'], true)比preg_match('/^[a-z]+$/')更可靠 - 枚举型参数（如状态、类型、格式）优先用白名单数组，而非正则或黑名单
- 路径拼接场景下，白名单应限定完整文件名（如
['report.pdf', 'invoice.xlsx']），而非仅校验后缀
为什么filter_var()和htmlspecialchars()不能替代白名单
filter_var() 是数据清洗工具，htmlspecialchars() 是输出编码工具——它们都不解决“这个值是否被授权用于当前上下文”的问题。
立即学习“PHP免费学习笔记（深入）”；
比如：filter_var($_GET['id'], FILTER_VALIDATE_INT) 能保证是数字，但无法阻止攻击者传入 id=9999999 绕过权限检查；htmlspecialchars($_GET['callback']) 能防XSS，但若该值被拼进 call_user_func($_GET['callback'])，照样触发任意函数调用。
- 白名单校验发生在逻辑分支之前，是第一道访问控制
- 输出编码只在渲染层起作用，对
file_get_contents()、shell_exec()、mysqli_query()等无防护力 - 任何将用户输入直接拼进动态函数名、类名、方法名、文件路径的位置，都必须白名单兜底
白名单校验放在哪里才真正生效
必须放在业务逻辑开始前、任何敏感操作执行前，且不能被绕过。最常出问题的是把校验写在条件分支里，或者放在中间件之后但又被后续代码重新赋值。
典型错误写法：if ($action === 'delete') { $id = $_POST['id']; } —— 此时 $action 本身未校验，攻击者可构造 action=delete&other_action=exec 并在后面用 $other_action 做坏事。
- 推荐统一入口校验：所有请求先过
validateInput()函数，返回失败立即exit或抛异常 - 避免在函数内部重复解析/重赋值输入，如
$cmd = $_GET['cmd']; $cmd = strtolower($cmd);后再判断，应在校验阶段就完成归一化 - 白名单数组建议定义为
const或配置文件，禁止从数据库或用户可控源读取
字符串比较用===还是==？为什么trim()有时反而危险
必须用严格比较 ===。PHP弱类型会让 '0' == false、'123abc' == 123 成立，白名单校验瞬间失效。
trim() 在某些场景会掩盖问题：比如白名单是 ['on', 'off']，而输入是 " on "，trim() 后能过，但若后续代码把该值拼进 shell 命令（如 "set_mode.php $mode"），空格可能被解释为参数分隔，导致命令注入。
- 白名单比对前，如需清理，只做最小必要处理：小写转换（
strtolower()）、去首尾空白（trim()），且必须在白名单数组中预置对应形式 - 对路径类输入，禁用
trim()，改用basename()+ 白名单双重约束 - 所有白名单校验后，原始输入变量应废弃，后续逻辑只使用校验通过后的干净值
白名单不是加一层 if 判断，而是把“允许什么”变成不可绕过的契约。最容易被忽略的是：校验后没中断执行流程，或校验对象不是最终参与敏感操作的那个变量。
