Iris默认不防CSRF因其轻量可定制设计，安全机制需开发者显式启用；必须手动集成Token生成、注入与校验，禁用gorilla/csrf等不兼容中间件，推荐原生方案：登录时生成带sessionID的Token，通过ViewData传入模板并SetCookie（SameSite=Lax, HttpOnly=false），POST/PUT/DELETE路由统一中间件校验FormValue或Header中的Token。
Iris 框架本身不内置 CSRF 防护，必须手动集成或借助中间件；直接依赖 gorilla/csrf 会因 Iris 的请求生命周期设计导致 Token 注入失败或校验绕过。
为什么 Iris 默认不防 CSRF？
Iris 是轻量、高度可定制的框架，所有安全机制都交由开发者显式启用。它没有像 Gin 的 gin-contrib/sessions + gin-contrib/csrf 那样开箱即用的组合，也没有自动绑定 Token 到模板上下文或响应头的逻辑。这意味着：
- 若只靠
iris.AddHandler或ctx.PostForm读取表单，_csrf字段会被忽略——除非你手动解析并校验 - 模板中调用
{{.CSRFToken}}不会自动生效，Iris 的context.View不提供默认 Token 变量 -
gorilla/csrf中间件与 Iris 的context不兼容：它依赖http.Handler接口，而 Iris 使用自定义context.Context封装，直接套用会导致 Token 无法写入 Cookie 或 Header
推荐方案：用 iris.AddHandler 手动注入 + 自定义中间件校验
最可控、适配性最强的方式是放弃通用中间件，改用 Iris 原生机制实现 Token 生命周期管理：
- 生成 Token：在登录成功或访问表单页时，用
securecookie或crypto/rand生成带用户标识（如sessionID）和时效（如 24h）的随机字符串 - 注入 Token：在渲染表单页面前，通过
ctx.ViewData("CSRFToken", token)传入模板；同时用ctx.SetCookie写入SameSite=Lax; HttpOnly=false; Secure=true的 Cookie（注意：HttpOnly 必须为 false，否则 JS 无法读取） - 校验时机：对所有
POST/PUT/DELETE路由，加一层中间件，从ctx.FormValue("_csrf")或ctx.GetHeader("X-CSRF-Token")读 Token，并比对 session 中存储的原始值 - 拒绝策略：校验失败时立即返回
ctx.StatusCode(403)并中断后续处理，不调用ctx.Next()
示例关键片段：
// 中间件校验
func CSRFVerify() iris.Handler {
return func(ctx iris.Context) {
token := ctx.FormValue("_csrf")
if token == "" {
token = ctx.GetHeader("X-CSRF-Token")
}
session := sessions.Default(ctx)
expected := session.Get("csrf_token")
if expected == nil || token != expected {
ctx.StatusCode(403)
ctx.WriteString("Forbidden: invalid or missing CSRF token")
return
}
ctx.Next()
}
}
// 表单页 handler（注入）
app.Get("/settings", func(ctx iris.Context) {
session := sessions.Default(ctx)
token := generateCSRFToken(session.ID())
session.Set("csrf_token", token)
session.Save()
ctx.ViewData("CSRFToken", token)
ctx.View("settings.html")
})
SameSite Cookie 是必须项，但不能单独依赖
SameSite=Lax 能拦截大部分第三方站点发起的 POST 请求（比如恶意表单提交），但它对以下场景无效：
- 攻击者控制的同站子域名（如
evil.example.com→app.example.com） - 使用
fetch(..., { credentials: 'include' })发起的跨域请求（现代前端常见） - 旧版浏览器（Chrome
因此，SameSite=Lax 应作为第一道防线，配合 Token 校验使用。设置方式：
ctx.SetCookie(&http.Cookie{
Name: "session_id",
Value: session.ID(),
SameSite: http.SameSiteLaxMode,
HttpOnly: true,
Secure: true, // 仅 HTTPS
})
容易被忽略的三个细节
实际部署中最常踩坑的是这三点：
- Token 存储位置：不要把 Token 存在
HttpOnlyCookie 里——前端拿不到，就无法随请求发出；应存 session 中，再通过非 HttpOnly Cookie 或模板变量下发 - GET 请求要不要校验：严格来说，
GET不该触发状态变更，但如果业务中存在GET /logout或GET /delete?id=123这类接口，必须同样校验，否则可被 - 前后端分离场景：若前端是 Vue/React 单页应用，Token 应从
/api/csrf接口获取并缓存到内存，每次请求通过X-CSRF-Token头发送；此时后端需额外开放该接口，且不允许被 CORS 共享凭据污染
真正难的不是写几行 Token 生成代码，而是让 Token 在整个请求链路中不丢失、不复用、不泄露——尤其是和 Iris 的 session 管理、模板渲染、CORS 配置交叉时，稍有错位就会失效。
