PHP 安全编码清单：从输入过滤到依赖供应链风险

在 PHP 开发的世界里，功能上线只是起点，真正考验功力的是应用上线后的安全防线。随着攻击手段的不断演进，以及开源生态的复杂化，现代 PHP 安全早已不只是避开 `$_GET` 里的黑客脚本那么简单。这是一份面向日常开发的安全编码清单，帮你从第一行代码到最终部署，把安全隐患尽量扼杀在摇篮里。

输入过滤：信任边界必须设在前端

每一个进入应用的变量，无论是来自用户表单、API 请求还是命令行参数，都是不可信的。很多新手喜欢用正则表达式去“过滤”恶意字符，但正确的思路是验证合法格式，而不是剔除非法内容。

例如获取一个用户 ID，不要盲信 `intval($_GET['id'])` 就万事大吉，要使用类型检查和范围约束：

$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT, 
    ['options' => ['min_range' => 1]]);
if ($id === false) {
    // 拒绝请求，而不是继续处理
}

在处理数组输入时，务必结合 `filter_input_array()` 或手动循环进行递归清洗。记住：过滤是手段，验证才是目的。对于文本型输入，保留原始数据，在输出环节进行转义，这就是 Laravel 等框架建议请求验证而非请求过滤的原因。

输出转义：别让 XSS 卷土重来

PHP 天然将 HTML 与业务代码混写的能力，成了 XSS（跨站脚本）攻击的温床。输出转义必须遵循上下文原则——在 HTML 内容、HTML 属性、JavaScript、URL 等不同位置，需要不同的转义策略。

对于普通 HTML 内容，强烈推荐 `htmlspecialchars()` 配合 `ENT_QUOTES` 标志：

echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');

如果你在构建富文本编辑器内容，请使用经过安全审计的 HTML 净化库（如 HTMLPurifier），而不是自己写正则剥离 `<script>` 标签——现在的攻击载荷早已学会伪装在 SVG、MathML 或事件属性中。如果是在 JavaScript 上下文输出，请使用 `json_encode()` 并配合 `JSON_HEX_TAG` 等方式，确保数据不会逃逸出字符串边界。

SQL 注入：参数化查询胜于一切花哨转义

PHP 的 `mysql_*` 系列函数早已废弃，但许多人仍习惯用字符串拼接构造 SQL。哪怕你对输入做了严格的 `addslashes()` 处理，也存在宽字节或多字节编码绕过风险。唯一且正确的解决方案是使用 PDO 或 MySQLi 的预处理语句（Prepared Statements）。

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $email]);

如果遇到动态表名或列名无法参数化的场景，必须建立白名单映射，人为规定允许的取值，切断一切可能注入的路径。请记住，预处理语句不是性能优化工具，而是安全承诺。

文件上传与路径穿越

文件上传是另一个重灾区。只检查 `$_FILES['file']['type']`（该值由客户端提供）等于掩耳盗铃。服务端需要双保险校验：先验证 `finfo` 获取的 MIME 类型，再检查文件头与扩展名是否一致。此外，存储文件名应重新生成随机字符串，并剥离原有文件路径。

处理文件下载或读取操作时，要防止路径穿越（`../`）攻击。不要将用户输入直接拼接到文件路径中，而是使用 `realpath()` 检查最终解析路径是否位于允许的根目录之内：

$baseDir = realpath('/var/www/uploads/');
$filePath = realpath($baseDir . '/' . $filename);
if ($filePath === false || strpos($filePath, $baseDir) !== 0) {
    exit('非法路径');
}

会话管理与 CSRF 防护

PHP 的默认会话 ID 容易遭受固定攻击和嗅探。在登录成功后，务必调用 `session_regenerate_id(true)` 丢弃旧的会话。同时为 Cookie 设置 `HttpOnly`、`Secure`、`SameSite=Lax` 属性，能否有效减少 XSS 窃取会话和跨站请求携带 Cookie 的风险。

CSRF 防护的核心是不可预测性。在用户执行修改、删除、支付等敏感操作时，表单中应包含服务器随机生成的 Token，并在提交时进行比对。框架内置的 CSRF 中间件已经足够可靠，但底层原理请务必了解：Token 必须绑定会话，且每次提交后判断是否过期。

密码存储与错误信息泄露

密码存储永远不要用 MD5 或 SHA1 加盐循环多次。PHP 内置的 `password_hash()` 与 `password_verify()` 是经过 RNG 自动加盐、且可灵活调整成本因子的标准答案。

$hash = password_hash($password, PASSWORD_DEFAULT);
if (password_verify($password, $hash)) {
    // 登录成功
}

在生产环境，务必关闭 `display_errors`，把错误日志写入文件。数据库异常信息、堆栈跟踪包含服务器路径和数据结构，是攻击者地图绘制的重要情报。给用户看的错误提示尽量模糊，但内部日志要详细记录请求 ID、来源 IP 等追踪字段。

依赖供应链：看不见的第三方风险

现代 PHP 开发离不开 Composer。除了攻击你的代码，黑客更倾向攻破被你信任的开源库。`vendor/` 目录里躺着几千个文件，你未必清楚它们正在执行的每一行逻辑。

对待 Composer 依赖必须像对待引入的生产代码一样严格。 第一，每次安装依赖后提交 `composer.lock` 文件，确保生产环境使用同一版本。第二，定期执行 `composer audit` 检查已知漏洞（PHP 生态已支持 Security Advisories 数据库）。第三，如果使用下载量不大、维护频率低的第三方扩展包——哪怕它提供了某个看似方便的功能——请三思而后行。你能维护它的风险，远高于自己写十几行代码的成本。

更进一步，在 CI/CD 流程中加入依赖扫描工具（如 SensioLabs Security Checker），并在生产环境锁定扩展的 SHA-256 校验和，避免恶意篡改。

打破黑箱：日志、监控与纵深防御

安全不是单个函数或框架能解决的问题，它是一个持续关注的过程。上面所有清单项都需要后续验证：你过滤了输入，但日志中的原始请求是否暴露了攻击尝试？你是否记录了所有需要审计的敏感操作？当更新了某个依赖库，是否重新跑过完整的黑盒测试？

建议在你的架构中引入纵深防御的思维：即便某个输入绕过了 XSS 过滤，输出转义与 CSP 头（内容安全策略）可以作为第二道、第三道防线。即使某个依赖被攻破，最小权限原则与沙箱执行环境也能将爆炸半径降至最低。

PHP 能成为世界上最流行的 Web 语言，很大程度上得益于它低门槛的普及率。但低门槛意味着开发者的纪律性尤为重要。这份清单不可能覆盖所有攻击面，但遵循这些基础实践，就能让应用从一个“能跑”的脚本，成长为一个值得被信任的系统。