Buffalo 的 CSRF 防护并非默认启用，必须显式调用 app.Use(csrf.Middleware) 且置于 session.Middleware() 之后；仅对非 GET/HEAD/OPTIONS 请求生效，需模板注入 token、配合 SameSite=Lax Cookie 及动词约束方可有效防护。
Buffalo 默认启用了 CSRF 中间件，但必须显式配置才生效
Buffalo 在 app.Use(csrf.Middleware) 被调用时才启用 CSRF 防护，它不是开箱即用的“默认开启”功能。很多项目在迁移或快速搭建时漏掉这行，导致看似有防护实则裸奔。
常见错误现象：POST /login 或 POST /profile 接口能被第三方页面直接表单提交成功，无任何 token 校验；浏览器 Network 面板里看不到 X-CSRF-Token 响应头，_csrf cookie 也未设置。
- 确认
app.Use(csrf.Middleware)出现在app.go的中间件注册链中，且位置在session.Middleware()之后（CSRF 依赖 session 存储 token） - 确保没有提前
return或next()跳过该中间件（比如在自定义 auth middleware 里误写return ctx.Next()而没调用next） - CSRF 中间件只对非 GET/HEAD/OPTIONS 请求生效——如果你用 GET 执行敏感操作（如
/logout?confirm=true），它完全不拦截
CSRF token 必须从 HTML 模板中正确注入，不能靠 JS 动态拼接
Buffalo 的 csrf.Token() 辅助函数只在模板渲染时可用，返回的是当前请求绑定的、已签名的一次性 token。前端若试图用 JS 从 DOM 读取再手动塞进 AJAX 请求头，极易出错。
使用场景：登录表单、修改邮箱、删除资源等 POST/PUT/PATCH 表单。
- 在 Buffalo 模板（如
login.html）中写：<input type="hidden" name="authenticity_token" value="<%= csrf.Token() %>"> - 不要把
csrf.Token()放在 JS 字符串里拼接，Buffalo 模板引擎不会执行其中的 Go 代码 - AJAX 请求需显式携带：在
fetch或axios的headers中加'X-CSRF-Token': document.querySelector('input[name="authenticity_token"]').value - 注意字段名必须匹配后端预期——Buffalo 默认检查
authenticity_token参数或X-CSRF-Token请求头，改名需同步调整csrf.Options
禁用自动 CSRF 保护的路由要格外小心
Buffalo 允许用 app.Post("/api/webhook", handler).Use(csrf.Skip) 跳过某路由的 CSRF 校验。但一旦跳过，该 endpoint 就彻底失去防护，攻击者可构造任意来源的 POST 请求触发它。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
容易踩的坑：
- 把支付回调、Webhook、第三方通知接口设为
csrf.Skip，却没做 IP 白名单或签名验证，等于主动打开后门 - 误以为 “API 接口不用防 CSRF”，忽略了浏览器发起的跨域 POST 仍会携带 Cookie（尤其当 SameSite 未设或设为
Lax时） - 跳过 CSRF 后，没补上替代验证（如 HMAC 签名、临时 access_token、Referer 白名单），风险直接暴露
CSRF 中间件和 SameSite Cookie 必须协同使用
仅靠 Buffalo 的 csrf.Middleware 不足以覆盖所有场景。如果用户浏览器较老（如 IE11）、或服务端未设置 SameSite 属性，恶意站点仍可能通过 iframe + form submit 绕过 token 校验。
性能与兼容性影响：
- Buffalo 默认不设置
SameSite，需手动在app.Use(session.Middleware())的选项中传入：session.Options{SameSite: http.SameSiteLaxMode} -
SameSite=Strict会破坏正常跨站跳转（如从营销页进登录页），Lax是更平衡的选择，但对 POST 表单提交仍允许携带 Cookie - CSRF token +
SameSite=Lax+ 正确的动词约束（不用 GET 改数据），三者缺一不可
真正容易被忽略的是：CSRF 防护效果高度依赖客户端行为。哪怕 Buffalo 配置完全正确，只要前端把 token 存进 localStorage 后又用 JS 拼到 URL 里（如 ?token=xxx），就可能被 Referer 泄露；只要后端允许 GET /logout，CSRF 中间件就形同虚设。防护不是加一行中间件就结束的事。
