PHP用户输入过滤技巧全解析

PHP用户输入过滤绝非一招鲜，而是贯穿数据全生命周期的四重防线：接收时用filter_input()严格验证类型与范围，存储前谨慎清理（避免已废弃的FILTER_SANITIZE_STRING），输出到HTML时务必调用htmlspecialchars()并显式指定ENT_QUOTES和UTF-8编码以防XSS，入库时坚持参数化查询实现语句隔离；任一环节缺失都可能被攻击者绕过，安全必须环环相扣、步步设防。

PHP过滤用户输入不是选一个函数就完事，而是按数据流向分阶段处理：接收时验证类型、存储前清理内容、输出前转义字符、入库时隔离语句。漏掉任一环节都可能被绕过。

filter_input() 获取并验证GET/POST参数更安全

直接读 $_POST['email'] 没做任何校验，等于把解析权交给攻击者。用 filter_input() 一步完成“取值 + 验证”：

• filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT) 返回整数或 false，不会返回字符串 "18abc"
• filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]]) 可带范围检查，避免传入负数或超大值
• 注意 FILTER_SANITIZE_STRING 在 PHP 8.1+ 已废弃，别再用；改用 filter_var($input, FILTER_SANITIZE_SPECIAL_CHARS) 或明确组合 trim() + htmlspecialchars()

htmlspecialchars() 必须在输出到HTML时调用

哪怕输入已用 filter_var() 验证过邮箱，只要它最终要 echo 到页面里，就必须过一遍 htmlspecialchars()。XSS 不发生在输入时，而发生在渲染时。

• 必须显式指定第三参数编码：htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，否则旧版 PHP 可能因默认编码不一致导致单引号绕过
• ENT_QUOTES 要带上，否则属性内插值如 <input value="<?=$name?>"> 仍可能被 " onclick=alert(1) 注入
• 不要依赖模板引擎自动转义——确认你用的引擎版本是否默认开启，以及是否覆盖了所有变量输出点

PDO预处理语句是防SQL注入的唯一可靠方式

别信 addslashes()、mysql_real_escape_string()（已废弃）或任何手动拼接加转义的方案。只有预处理能从根本上切断 SQL 结构与数据的耦合。

• 占位符必须是 ? 或 :name，不能把变量拼进 SQL 字符串里，例如 "WHERE id = " . $_POST['id'] 是高危写法
• 连接需设错误模式：new PDO($dsn, $user, $pass, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION])，否则绑定失败可能静默忽略
• 数值型参数不用额外转 int，$stmt->execute([$_POST['id']]) 中的字符串 "123" 会被数据库当作数值处理，前提是字段类型匹配

白名单正则过滤只用于强格式约束场景

当业务要求用户名只能是字母数字下划线、手机号必须11位纯数字时，filter_var() 不够用，得上 preg_match() 白名单。

• 用 ^ 和 $ 锚定首尾：preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)，否则 "admin 也能部分匹配成功
• 清理优先用 preg_replace() 删除非法字符，而不是 preg_match() 后丢弃整个字段——除非业务规则严格禁止模糊容忍
• 别用黑词表（如屏蔽 "script"），攻击者可轻松变形绕过，白名单才是唯一可信路径

最常被忽略的是：同一份用户输入，在不同上下文要走不同过滤链。比如一个昵称字段，入库前用 trim() + 白名单正则，存进数据库；查出来后显示在页面要过 htmlspecialchars()；若还要放进 JS 变量，则得用 json_encode() 包裹。没有“一次过滤，到处适用”的银弹。

今天关于《PHP用户输入过滤技巧全解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！