Laravel CSRF防护_CSRF Token验证原理【方法】

先说几个核心判断：CSRF Token验证绝不是“加个@csrf就完事”那么简单。它依赖session存活、请求路径匹配、中间件执行顺序三个硬条件，缺一不可，少一个都不行。

CSRF Token 验证不是“加个 @csrf 就完事”，它依赖 session 存活、请求路径匹配、中间件执行顺序三个硬条件，缺一不可。

VerifyCsrfToken 中间件怎么判断请求是否合法

这个中间件定义在 App\Http\Middleware\VerifyCsrfToken 里，核心逻辑其实很简单：从请求里提取 token——优先看 X-CSRF-TOKEN 请求头，其次再检查表单里的 _token 字段——然后跟当前 session 中存储的 _token 值做比对。

有几个关键点需要留意：

• session 必须处于已启动且未过期的状态。如果用户长时间没操作，session 被销毁，token 也就跟着丢了。这时候所有 POST/PUT/DELETE 请求都会直接返回 419 Page Expired，页面直接罢工。
• 这个中间件只对 web 中间件组生效，默认不处理 api 路由。所以、路由下的请求是天然被豁免的——但这同时也意味着，你不能指望用它来保护 API 端点安全。
• 如果请求 URL 正好落在了 $except 数组里（比如 webhook/stripe），中间件会直接跳过验证，不会抛出异常。

@csrf 指令生成的 hidden 字段为什么有时不生效

@csrf 编译后生成的是 ，这个大家都很熟悉。但它只在 Blade 模板里起作用，而且有两个前提：

• 当前响应必须由 Lara vel 渲染，也就是说必须走 web 路由。否则 session 写不进去，token 自然也生成不了。
• 不能在非 session 的上下文中调用。举个例子，通过 php artisan tinker 手动渲染一段 Blade 片段，这时候 @csrf 输出的就是一个空字符串。
• 如果页面被 CDN 缓存，或者服务端启用了静态 HTML 输出，问题就更麻烦了——@csrf 会被固化成一个旧值，后续提交必然失败。

常见的错误现象是 TokenMismatchException 或者 419 错误。打开浏览器开发者工具，能看到 _token 字段明明存在。这说明问题根本不在字段缺失，而是 session 和字段值不同步了。

AJAX 请求如何正确携带 CSRF Token

Lara vel 并不会自动为 AJAX 请求设置 token，需要手动注入。最稳妥的方式是从 标签里读取：

然后在 JS 中设置全局 header：

axios.defaults.headers.common['X-CSRF-TOKEN'] = document.querySelector('meta[name="csrf-token"]').getAttribute('content');

这里有几点需要注意：

• 这个 标签必须出现在 HTML 的 中，而且必须由 Lara vel 渲染——纯静态 HTML 是做不到的。
• 如果用的是 fetch，需要显式传入 header：headers: { 'X-CSRF-TOKEN': token }。它不像 axios 那样能自动继承 default headers。
• 如果前端是独立部署的 SPA（比如 Vue/Vite 项目），情况就更复杂了。后端必须通过接口返回 token，或者配置 CORS 允许读取 cookie 和 session，否则无法共享 session 中的 token。

为什么有些 POST 请求没报错却绕过了 CSRF 验证

这听起来像漏洞，但其实不是。它是 Lara vel 的显式放行机制在起作用：

• 路由前缀匹配了 $except：比如你在 VerifyCsrfToken.php 里写了 protected $except = ['api/*']，那么所有 /api/v1/user 类的请求都会跳过验证。
• HTTP 方法被忽略：CSRF 中间件默认只拦截 POST、PUT、PATCH、DELETE 这几种方法。但如果你用 GET 提交敏感操作——比如 GET /user/delete?id=123——它根本不校验。这不是防护失效，而是设计上的一个缺陷。
• 中间件没注册到路由组：如果用 Route::middleware(['api']) 定义路由，而 api 组里没包含 VerifyCsrfToken，那自然就不会验证。

真正容易被忽略的是：CSRF 防护和用户认证是两码事。就算关掉了 VerifyCsrfToken，只要还在用 auth 中间件，用户依然需要登录。但登录成功不等于请求合法——攻击者完全可以诱导一个已登录的用户点击恶意链接，直接触发一个没有 token 的 POST 请求。这才是真正需要警惕的地方。