Iris 框架需手动实现 CSRF 防护：1. 渲染 HTML 时用 ctx.ViewData 传入 Token 并在模板中显式插入隐藏字段；2. 校验时严格比对 ctx.PostValue("csrf_token") 与 ctx.GetCookie("csrf_token")；3. Token 必须强绑定用户 session，禁用 URL 传递，合理设置 SameSite=Lax 并管理生命周期。
Iris 框架本身不内置 MVC 分层结构，也没有像 Spring Security 或 ASP.NET MVC 那样的开箱即用 [ValidateAntiForgeryToken] 注解或自动 Token 注入机制。想在 Iris 中实现 CSRF 防护，必须手动集成 Token 生成、注入、校验三步逻辑——而且不能依赖框架“自动做”，否则极易漏掉 POST/PUT/DELETE 接口的校验。
怎么给每个页面响应注入 CSRF Token（HTML 渲染场景）
如果你用 iris.HTML 渲染模板（如 html/template 或 pongo2），需在每次返回 HTML 前生成并传入 Token：
- 用
iris.CSRF中间件（Iris v14+ 内置）可生成 Token 并写入 Cookie，但默认不自动注入到模板变量里；你得手动从ctx.Values().Get("csrf_token")取值 - 更稳妥的做法是：在 handler 里调用
ctx.GetCookie("csrf_token")或直接用iris.CSRF提供的Token(ctx)函数生成并缓存一次，再通过ctx.ViewData传给模板 - 模板中要显式写
<input type="hidden" name="csrf_token" value="{{ .CSRFToken }}">，不能靠 JS 自动读 Cookie 填充——因为 SameSite=Lax 下，跨站表单提交时 Cookie 不会携带，必须靠服务端注入的隐藏字段
怎么校验 POST 请求里的 CSRF Token
CSRF 校验不是“有 Token 就行”，关键在于比对时机和来源一致性：
- 必须在
ctx.PostValue("csrf_token")和当前会话绑定的 Token（比如从 Cookie 或内存 Map 中取）做严格字符串比对，不能只检查非空 - 不要在中间件里统一拦截所有 POST——Iris 的中间件是全局的，而有些接口（如文件上传回调、第三方 webhook）本就不该走 CSRF 校验；建议用
ctx.Application().Handle("POST", "/api/xxx", csrfCheckHandler, realHandler)显式包裹敏感路由 - 如果用了
iris.CSRF中间件，它默认把 Token 存进 Cookie（csrf_token），但不会自动验证请求体；你仍需自己写校验逻辑，例如：if ctx.PostValue("csrf_token") != ctx.GetCookie("csrf_token") { ctx.StatusCode(403); return }
为什么用 Cookie + 表单字段双重存储容易出错
这种“双重提交 Cookie”模式在 Iris 里看似省事，实则埋了三个坑：
- SameSite 属性没设对：若 Cookie 是
SameSite=Strict，跳转回站内页面时可能丢失 Token；设成Lax才能兼容大多数表单提交，但需确认你的前端发起的是常规 form submit，而非 fetch + credentials: 'include' - CSRF Token 生命周期管理缺失：Iris 不自动清理过期 Token，如果你用内存 map 存 Token（比如
sync.Map），必须配定时清理或基于 session ID 绑定 TTL，否则内存泄漏 - AJAX 请求头不一致：前端用
fetch提交时，Token 得从 Cookie 读出来塞进X-CSRF-Token头，而后端要从ctx.Header("X-CSRF-Token")读——这和表单提交走PostValue是两套路径，容易漏校验其中一种
最常被忽略的一点：CSRF Token 必须和用户 session 强绑定，不能复用、不能跨 session 传递；哪怕只是把 Token 放进 URL 查询参数（如 ?t=xxx），也会导致日志泄露、Referer 泄露、CDN 缓存污染——这些在 Iris 这类轻量框架里，全靠开发者自己掐住边界。
