Fiber框架的CSRF防护不支持按路由单独启用或禁用,因其csrf.New()是全局中间件,统一作用于所有后续路由;需通过前置注册静态/公开路由、分离router实例或手动路径判断实现细粒度控制。

不能按路由单独开 CSRF 防护——Fiber 的 csrf.New() 是全局中间件,不支持 per-route 启用或禁用。 试图只给 /api/transfer 加而放过 /api/public,要么全绕过,要么全拦截。真要细粒度控制,得靠手动跳过逻辑 + 显式校验,而不是依赖配置开关。
为什么 Fiber 没有路由级 CSRF 配置选项
Fiber 的 csrf.New() 返回的是一个标准中间件函数,它在请求进入时统一检查方法(POST/PUT/DELETE 等)和 Token 有效性,不感知路由路径。它不像 Gin 的 Group.Use() 那样可嵌套到子路由,也不像 gorilla/csrf 那样允许用 http.HandlerFunc 包裹单个 handler。
- Fiber 中间件链是线性的,
app.Use(csrf.New())会作用于所有后续注册的路由,包括GET /health - 它默认对所有非安全方法(
POST,PUT,DELETE,PATCH)强制校验,不管路径是否敏感 - 没有
csrf.SkipPaths或csrf.Except(...)这类内置配置项
如何实现“路由级”效果:跳过静态资源与公开接口
必须手动识别并放行不需要防护的路径,否则浏览器自动请求 /favicon.ico 或前端健康检查都会 403。关键不是“配置”,而是“显式排除”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器,提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象,支持命名依赖等
- 在调用
csrf.New()前,先注册静态资源路由:app.Static("/static", "./public")—— Fiber 会优先匹配,不进中间件链 - 对明确公开的 API(如
GET /api/status),改用app.Get("/api/status", handler)在csrf.New()之前注册 - 若必须共用中间件链,可在 handler 内部用
c.Path()判断路径,手动return跳过校验(但此时 Token 已被中间件消耗,不可取) - 更稳妥的做法:把公开接口放在独立 router 实例里,不套
csrf.New()
敏感路由必须显式确保 Token 传输通道匹配
跳过不难,难的是让真正需要防护的路由不出错。403 不是因为没加中间件,而是前端传错了 Token 位置。
立即学习“go语言免费学习笔记(深入)”;
- Fiber CSRF 默认只从两个地方读 Token:
X-Csrf-Token请求头(AJAX)或_csrf表单字段(传统 form) - 前端 fetch 必须带
credentials: 'include',否则 Cookie 不发,服务端 session 找不到对应 token - 别把 token 存 localStorage —— XSS 可直接读,应从
document.cookie解析或模板直出 - Cookie 属性必须设
SameSite: "Lax"和Secure: true(生产环境),否则浏览器可能拒绝发送
真正容易被忽略的点:Fiber 的 CSRF 中间件不会自动帮你生成 HTML 表单隐藏字段,你得自己在模板里写 <input type="hidden" name="_csrf" value="{{.CSRFToken}}">,或者用 JS 从 Cookie 提取后塞进 header —— 这一步漏了,哪怕中间件开着,也永远 403。


















