Laravel中如何配置表单安全令牌以避免CSRF攻击？

本文共计1195个文字，预计阅读时间需要5分钟。

由于 Laravel 默认启用全局 CSRF 保护，所有使用 POST、PUT、PATCH、DELETE 等请求方法的数据提交都需要携带有效的 CSRF token。如果中间件 VerifyCsrfToken 检测到没有有效的 CSRF token，将直接返回 419 页面。这不是配置漏洞，而是框架的安全策略默认行为。

常见错误现象：
• 提交自定义 HTML 表单（没用 Blade）时 419
• AJAX 请求没带 X-CSRF-TOKEN 头，返回 419 或 403
• 在 Vue/React 单页应用中复用 Laravel 后端，token 过期或未刷新

• Blade 模板里必须写 @csrf（它会生成隐藏 input：<input type="hidden" name="_token" value="...">）
• AJAX 请求需从 <meta name="csrf-token" content="..."> 读取值，并设请求头 X-CSRF-TOKEN
• 不要手动拼接 _token 值——session 中的 token 是绑定 session ID 的，硬编码会失效

VerifyCsrfToken 中间件怎么排除特定路由

有些接口本就不该走 CSRF 校验，比如 Webhook 接收地址、API 端点（尤其用 API Token 或 JWT 认证时）。Laravel 允许白名单排除，但得小心路径匹配逻辑。

使用场景：
• 第三方服务回调（如 Stripe、微信支付）
• 前后端分离项目中纯 API 路由
• 内部系统间 HTTP 调用（已通过 IP 或签名鉴权）

• 在 app/Http/Middleware/VerifyCsrfToken.php 的 $except 数组里填路径，支持通配符：'api/webhook/*'、'admin/export'
• 路径匹配基于路由定义的 URI，不是完整 URL，不包含域名或 query string
• 排除后该路由彻底跳过 token 校验——别误加到登录、密码重置等敏感操作上
• 如果用 Route::middleware('web') 包裹了 API 路由，即使写了 $except 也可能因中间件顺序问题仍被拦截；确认路由属于 api 中间件组更稳妥

CSRF token 刷新时机和失效原因

Laravel 的 CSRF token 绑定当前 session，每次 session 写入（比如登录、regenerate）都会刷新。但用户无感知的失效更常来自缓存或并发请求。

常见错误现象：
• 表单页面打开很久再提交，报 419
• 同一账号在两个标签页同时操作，一个成功一个失败
• 使用 Nginx 缓存了含 @csrf 的 Blade 页面，token 固定不变

• token 存在 session 中，默认有效期 = session 生命周期（通常 2 小时），不受 cache.ttl 影响
• Blade 模板不能被静态缓存——Nginx 或 CDN 缓存含 @csrf 的 HTML 会导致所有用户拿到同一个旧 token
• Vue/React 前端若从服务端首次获取 token 后长期复用，需监听 419 响应并主动刷新（调用 /sanctum/csrf-cookie 或重新拉首页）
• 不要在 JS 里用 document.querySelector('input[name=_token]').value 动态取值后长期缓存——它不会自动更新

API 场景下要不要关 CSRF？关了安不安全？

要关，但不是靠关中间件，而是靠路由分组。Laravel 的 api 中间件组默认不启用 VerifyCsrfToken，这是设计使然——API 应该用 stateless 认证（如 Bearer Token、JWT），CSRF 对无 cookie 的请求无效。

容易踩的坑：
• 把 API 路由写在 routes/web.php 里，结果被 web 中间件包裹，意外触发 CSRF 校验
• 用 auth:sanctum 却把前端 Cookie 模式和 Token 模式混用，导致 token 不一致
• 在 API 路由里手动加 ->middleware('web')，等于自己绕回 CSRF 流程

• API 路由必须定义在 routes/api.php，且不显式加 web 中间件
• 如果必须用 web 组但又想跳过 CSRF，优先走 $except 白名单，而不是删中间件——避免影响其他路由
• CSRF 防护只对 cookie 认证有效；用 API Token 时，攻击者拿不到 token，CSRF 自然无意义——但前提是真正不用 cookie

token 绑定 session 这个机制本身没问题，问题多出在缓存、路由分组错配、或前端没理解 token 的生命周期。盯住 session 和中间件这两层，比调参数更管用。