PHP CSRF 表单防护实战：令牌生成、提交校验和过期处理

很多后台系统都有修改资料、删除记录、提交订单这类表单。如果用户已经登录，攻击页面诱导浏览器发起一次跨站提交，服务端又只看 Cookie 登录态，就可能误把这次请求当成用户本人操作。

CSRF 防护的核心思路很直接：服务端为表单生成一个随机令牌，保存到 session，页面提交时把令牌一起带回来。服务端只有在令牌匹配、未过期、来源合理时才处理业务。

适合人群

适合正在写 PHP 后台表单、管理系统、个人中心、订单确认页的开发者。你需要了解基础表单提交、Cookie、session 和 PHP 数组。

目录

• 为什么只靠登录态不够
• 生成令牌并写入 session
• 表单提交时如何校验
• 失败原因和用户提示怎么设计
• 常见坑位和上线建议

为什么只靠登录态不够

浏览器会自动携带同站 Cookie。如果攻击页面构造了一个提交到你站点的表单，用户又正好登录着，服务端可能会收到一条带 Cookie 的请求。

因此，服务端不能只判断“有没有登录”。它还要判断这个提交是不是从你自己的页面发起。CSRF 令牌就是为了解决这个问题：攻击页面不知道服务端临时生成的令牌，也无法提交正确值。

下面这张图展示推荐链路：打开表单时生成令牌，写入 session 和隐藏字段，提交时服务端取回令牌并校验，通过后才进入业务处理。

生成令牌并写入 session

生成令牌时要使用足够随机的值，并且保存生成时间。下面是一个简化函数：

表单页面把令牌写入隐藏字段：

    保存

这里使用 htmlspecialchars 是为了避免令牌输出到 HTML 时引起额外问题。

表单提交时如何校验

提交处理页要先校验令牌，再处理业务。不要先写数据库再补校验。

 1800) {
        return false;
    }

    return hash_equals($saved, $token);
}

$token = $_POST['csrf_token'] ?? '';

if (!csrf_check($token)) {
    http_response_code(419);
    echo '表单已失效，请刷新后重试';
    return;
}

// 通过校验后再处理资料保存
echo '保存成功';
?>

hash_equals 用于安全比较字符串，避免普通比较在极端情况下暴露时间差异。令牌过期时间可以根据业务调整，例如 30 分钟或 2 小时。

失败原因和用户提示怎么设计

CSRF 校验失败时，不建议直接显示“攻击请求”。用户更常见的感知是页面停留太久、开了多个标签页、登录态变化、浏览器回退后提交。

下面这张图列出常见失败原因：令牌缺失、令牌不匹配、令牌过期、session 丢失，最终统一拒绝并提示刷新页面。

常见坑位和上线建议

第一，所有写操作都要校验。 修改资料、删除记录、创建订单、绑定账号这类请求都应该检查令牌。

第二，不要把令牌写死在配置里。 令牌应该按会话生成，必要时按表单刷新。

第三，配合 SameSite Cookie。 令牌是主防线，Cookie 的 SameSite=Lax 或 Strict 可以进一步降低跨站提交风险。

第四，失败日志要能定位。 记录用户 ID、接口路径、失败原因和时间，不要记录完整 Cookie 或敏感字段。

第五，接口和页面策略分开。 传统表单适合 CSRF 令牌；纯 API 通常还要配合请求头、来源校验和登录态策略。

总结

PHP 表单的 CSRF 防护可以从三步落地：打开页面时生成随机令牌并保存到 session，表单提交时带回令牌，服务端先校验令牌和有效期，再处理业务。

这套机制不复杂，但非常关键。只要把写操作统一接入校验，再配合合理的失败提示和日志，后台表单的误提交风险会明显降低。