Fiber默认不启用任何安全防护，所有中间件必须显式注册；CSRF中间件需调用app.Use(csrf.New())且置于敏感路由前，依赖session时须在session中间件之后注册，否则无法启用同步令牌模式。
Fiber 默认不开启任何安全防护，所有中间件都必须显式注册，漏掉一个就等于在生产环境裸奔。
CSRF 中间件必须手动启用且顺序不能错
Fiber 的 csrf.New() 不是默认加载的——不调用 app.Use(csrf.New())，就等于没 CSRF 防护。更关键的是，它必须放在所有需防护路由之前，否则对 app.Post("/api/transfer", handler) 这类路由完全无效。
- 正确顺序：先
app.Use(csrf.New())，再定义敏感路由（如/api/settings、/user/update） - 静态资源或健康检查（如
/health、/public/*）可放中间件之前，避免无谓校验 - 若已配置 session（如
session.New(session.Config{})），CSRF 中间件必须注册在 session 之后，否则拿不到 session 实例，无法启用同步令牌模式
双提交 Cookie 模式下前端必须桥接 token
默认双提交 Cookie 模式下，Fiber 会设 Set-Cookie: csrf_token=xxx，但浏览器不会自动把它塞进 X-CSRF-Token 请求头——这是两个独立位置，必须手动读取并设置。
- 表单提交：需在 HTML 中插入隐藏字段
<input type="hidden" name="csrf_token" value="{{.CSRFToken}}"> - AJAX 请求（fetch）：即使
credentials: 'include'发送了 Cookie，也得用 JS 显式读取document.cookie或解析响应头，再设headers: { 'X-CSRF-Token': token } - 注意：
csrf_tokenCookie 默认未设SameSite，生产务必补上SameSite=Lax或Strict，防止跨站 POST 自动携带凭证
Referer 和来源白名单不能只靠中间件默认值
Fiber 的 CSRF 中间件支持 csrf.Config.TrustedOrigins 配置可信源，但默认为空——意味着不校验 Referer，攻击者可通过 iframe + 表单自动提交绕过 token 校验。
- 敏感接口必须显式配置白名单，例如
TrustedOrigins: []string{"https://myapp.com", "https://admin.myapp.com"} - 若接口允许被第三方 iframe 嵌入，必须加
sandbox="allow-scripts allow-same-origin"，并移除allow-forms，直接阻断表单自动提交路径 - 仅配
TrustedOrigins不够：攻击者可伪造 Referer，所以 token 校验仍是第一道防线，Referer 是辅助层
JWT 认证和 WebSocket 握手阶段必须分离处理
Fiber 的 keyauth.New() 可用于 WebSocket 升级请求认证，但必须用 Next 函数跳过非 WebSocket 请求，否则普通 HTTP 接口也会被强制校验，导致 401。
- 认证逻辑应写在
keyauth.Config.Validator中，提取方式推荐组合使用：extractors.FromAuthHeader("Bearer")和extractors.FromQuery("token") - WebSocket 握手时，
c.IsWebSocket()返回true才触发验证；普通 API 路由不应混用同一套 keyauth 中间件 - 不要把 JWT 解析逻辑写在
websocket.Handler内部——握手已完成，此时再拒绝连接会返回 400 而非标准升级失败响应
真正容易被忽略的点是：CSRF 中间件和 session 中间件的注册顺序、Cookie 的 SameSite 属性、以及 WebSocket 认证与普通 API 认证的分流控制——这三处一旦出错，防护就形同虚设，且问题往往在线上才暴露。
