net/http 不提供 CSRF Token 因其定位为底层工具集，CSRF 防护需手动实现：用 crypto/rand 生成 32 字节随机 token，base64.URLEncoding 编码后存入 session 并注入表单；POST 时须解析表单、恒定时间比对并立即清除 token；SameSite Cookie 不足以替代 token，尤其对敏感操作。
为什么默认的 net/http 不提供 CSRF Token？
Go 标准库的 net/http 定位是底层 HTTP 工具集，不内置 Web 框架级功能，CSRF 防护需手动集成。这意味着你无法直接调用类似 csrf.Token(r) 这样的函数——它不存在于标准库中，必须自己生成、存储、校验并注入到表单。
如何安全生成和绑定 CSRF Token 到 HTML 表单？
Token 必须满足：加密随机、单次有效（或短时效）、与用户 session 绑定。推荐使用 crypto/rand 生成 32 字节 token，并用 encoding/base64.URLEncoding 编码为 URL 安全字符串。Token 应写入用户 session（如基于 gorilla/sessions），同时通过 template 注入到每个需要防护的表单中：
func loginHandler(w http.ResponseWriter, r *http.Request) {
session, _ := store.Get(r, "session-name")
token := make([]byte, 32)
rand.Read(token)
encoded := base64.URLEncoding.EncodeToString(token)
session.Values["csrf_token"] = encoded
session.Save(r, w)
tmpl.Execute(w, map[string]string{"CSRFToken": encoded})
}
对应 HTML 模板中写：
如何在 POST 处理中验证 CSRF Token？
验证必须在业务逻辑前完成，且需严格比对：从表单读取 csrf_token 字段，从 session 中取出原始 token，二者必须完全相等（恒定时间比较更佳）。常见错误包括：
立即学习“go语言免费学习笔记（深入）”；
- 未检查 token 是否存在，导致空值绕过
- 从 query string 而非 form value 读取 token（GET 请求无意义）
- 校验后未清除 session 中的 token（应设为一次性）
示例校验逻辑：
func verifyCSRF(r *http.Request) error {
err := r.ParseForm()
if err != nil {
return err
}
submitted := r.FormValue("csrf_token")
session, _ := store.Get(r, "session-name")
expected, ok := session.Values["csrf_token"].(string)
if !ok || subtle.ConstantTimeCompare([]byte(submitted), []byte(expected)) != 1 {
return errors.New("invalid csrf token")
}
delete(session.Values, "csrf_token") // 一次性使用
session.Save(r, nil)
return nil
}
为什么不能只依赖 SameSite Cookie？
SameSite=Lax 或 Strict 可缓解部分 CSRF，但不等于防护完备。Lax 允许 GET 表单提交（如银行转账链接被诱导点击），Strict 在跨站导航时会丢失 cookie，影响用户体验；且旧浏览器（如 IE11）不支持。CSRF Token 是唯一可跨浏览器、跨场景、明确可控的防御手段。尤其当你的表单包含敏感操作（删除、支付、权限变更），必须配合 token 验证，不能仅靠 Cookie 属性。
真正麻烦的是 token 生命周期管理——比如用户长时间停留页面后提交，token 已失效，需友好提示并刷新；又比如多标签页并发操作，要考虑是否允许多个有效 token。这些细节没处理好，安全就变成体验黑洞。
