Fiber默认不内置CSRF中间件，必须手动集成csurf.New()并配置store、CookieSameSite、CookieSecure等参数，且需区分场景选择双提交Cookie或同步令牌模式，静态资源和API接口应排除校验。
Fiber 框架默认不内置 CSRF 中间件，也没有类似 Spring Security 那样开箱即用的自动令牌管理机制。所以你不能直接启用一个开关就完成防护——必须手动集成、生成、校验和传递 token，否则请求会被无差别拦截。
这恰恰是容易出问题的地方：很多人以为加个中间件就万事大吉，结果漏掉前端埋点、token 生命周期管理或忽略静态资源路径，导致登录页 403、AJAX 请求失败、甚至误放行 POST 接口。
为什么 Fiber 没有默认 CSRF 中间件
Fiber 的设计哲学是「轻量 + 显式」：它把安全决策权交给开发者，避免隐藏行为（比如自动注入 header、悄悄读取 cookie、或对 GET 请求做 token 校验）。这意味着：
- CSRF 防护不是“配个开关”，而是要自己选 token 存储方式（session / cookie / memory）、决定哪些方法/路径需要防护（通常只限
POST/PUT/DELETE） - 没有内置 session 管理，你得先接入
fiber/storage或自己实现Store接口，否则csrf.New()会 panic - 默认不设
SameSite属性，若用 cookie 存 token 却没配SameSite=Lax或Strict，防御效果大打折扣
用 github.com/gofiber/fiber/v2/middleware/csrf 配置
官方维护的 csrf 中间件在 github.com/gofiber/fiber/v2/middleware/csrf，但注意它只负责生成和校验 token，不处理前端渲染或自动携带逻辑。
典型配置如下：
app := fiber.New()
<p>// 必须先配置 store（例如基于内存）
store := storage.NewMemory()</p><p>app.Use(csrf.New(csrf.Config{
KeyLookup: "header:X-CSRF-Token", // 从 header 读 token
TokenLength: 32,
TokenLookup: "cookie:_csrf", // 生成时写入此 cookie
CookieName: "_csrf",
CookieSameSite: http.SameSiteLaxMode, // 关键！防止被第三方站点发起带 cookie 的请求
CookieSecure: true, // 生产环境务必开启（配合 HTTPS）
SessionStore: store, // 必须非 nil，否则启动报错
}))
-
KeyLookup和TokenLookup要匹配：前端发请求时需从_csrfcookie 里取值，塞进X-CSRF-Tokenheader - 如果用表单提交，得手动在
<form>里加<input type="hidden" name="_csrf" value="{{.CSRFToken}}">——Fiber不像 Django 那样自动 inject -
CookieSameSite设为Lax是底线；设Strict可能影响正常跳转（如从邮箱点击链接进站），需权衡
哪些路由该跳过 CSRF 校验
不是所有 POST 都需要 CSRF 防护。硬套中间件到全局，会导致 API 接口（尤其是 JWT 认证的）因缺少 cookie/token 而全部 403。
- 静态资源路径（
/assets/*、/favicon.ico）必须排除，否则图标都加载不了 - 公开接口（
/api/public/register）无需用户登录态，自然也不需要 CSRF - 纯 API 服务（如前后端分离项目中，前端用 Bearer Token 认证）——此时应关闭 CSRF，改用 token 绑定 origin/referer 校验（见下条）
- 若必须对 API 开 CSRF，得确保前端每次请求前先 GET
/csrf-token接口拿 token，并在后续请求中带上
前后端分离场景下的替代方案
当你的前端是 Vue/React 独立部署（比如跑在 https://fe.example.com），后端 API 在 https://api.example.com，此时 cookie 共享失效，csrf.New() 默认模式基本不可用。
可行做法是放弃 cookie + header 模式，改用：
- 校验
Origin或Refererheader（仅限 HTTPS 环境，且Referer可被客户端清除） - 要求前端在请求 header 中固定携带
X-Requested-With: XMLHttpRequest（旧式 jQuery 默认加，现代 fetch 不加，需手动设） - 更稳妥的是：在登录成功后，后端返回一个短期有效的
csrf_token字段，前端存入内存（非 localStorage），每次敏感请求附在 body 或 header 中，后端比对并消耗该 token（one-time use）
这种模式绕开了 cookie 限制，但也意味着你要自己实现 token 生成、存储、过期与销毁逻辑——Fiber 的 csrf 中间件帮不上忙。
实际部署时最容易被忽略的，是 CookieSameSite 和 CookieSecure 的组合配置。本地开发用 HTTP 时设 CookieSecure=true 会导致 cookie 不写入，而生产环境漏掉 SameSite 则等于没防。
