fiber的csrf中间件默认启用双提交cookie模式，但必须显式调用app.use(csrf.new())且置于路由定义之前才生效；未配置则无防护，字段名不匹配或漏挂中间件均导致防护失效。
Fiber 的 CSRF 中间件默认启用双提交 Cookie 模式，但必须显式注册才能生效——不加中间件，就等于没防护。
CSRF 中间件必须手动 use 才生效
Fiber 不像某些框架自动注入安全中间件。即使你调用了 app.Use(csrf.New())，若未在路由前调用（比如写在 app.Post("/api/submit", handler) 之后），该中间件对后续路由完全不生效。
- 正确顺序：先
app.Use(csrf.New())，再定义所有需防护的路由 - 敏感接口（如
/api/transfer、/user/settings）必须落在中间件链下游，否则 token 校验被跳过 - 静态资源（
/public/*）或健康检查（/health）可放中间件之前，避免无谓校验
双提交 Cookie 模式下，前端必须同步传 token
默认模式不依赖 session 存储，token 由中间件生成并设为 csrf_token Cookie；但客户端必须在请求头或表单字段中重复携带该值，服务端才比对。
- POST 表单需含隐藏字段：
<input type="hidden" name="csrf_token" value="{{.CSRFToken}}"> - AJAX 请求需读取 Cookie 并设头：
headers: { 'X-CSRF-Token': token } - 浏览器不会自动把
csrf_tokenCookie 塞进X-CSRF-Token头——这是两个独立位置，必须手动桥接 - 若用
fetch且 credentials: 'include'，Cookie 会发，但头仍需 JS 显式提取并设置
启用同步令牌模式要配 session 存储
当应用已使用 session.New() 并配置了存储（如 Redis、badger），Fiber 会自动降级为同步令牌模式——token 绑定 session ID，更难被预测重放。
- 必须提前初始化 session 中间件：
app.Use(session.New(session.Config{...})) - CSRF 中间件要在 session 之后注册，否则拿不到 session 实例
- 此时 token 不再仅靠 Cookie 双提交，而是从 session 数据里取出比对，即使 Cookie 被窃也无法伪造
- 注意：内存存储（
session.New()无参数）只适合开发，生产必须换持久化后端
iframe 场景下不能只靠中间件
CSRF 中间件管不了 iframe 加载本身，但攻击者常借 iframe 触发跨域表单提交或图片请求。光有 token 校验不够，得配合其他层：
- 敏感接口必须拒绝非同源
Referer（Fiber 的csrf.Config.TrustedOrigins可配白名单） - 设置
SameSite=Lax或Strict的会话 Cookie，让浏览器不自动带凭证发跨站 POST - 对必须嵌入的第三方 iframe，用
sandbox="allow-scripts allow-same-origin"严格限制，去掉allow-forms可直接阻断自动表单提交路径 - GET 类状态变更接口（如
/api/user/delete?id=123）同样要校验 token——中间件默认只拦截非 GET/HEAD，需手动开启AllowGetRequests: true
最容易漏的是：token 字段名硬编码错误（比如前端传 _csrf，后端等 csrf_token），或者在 API 路由上忘了挂中间件——这两处一错，整个防护形同虚设。
