Go Cookie 怎么设置才安全：HttpOnly、SameSite、Secure 与代理边界

登录接口返回200只是第一步，真正容易被开发者遗漏的配置项就在响应头的 Set-Cookie 里。如果会话 Cookie 没开 HttpOnly，页面脚本可以直接把完整明文内容读走；如果跨站请求还能自动带上 Cookie，CSRF 风险根本就没被管控住；如果 HTTPS 在反向代理处终止，却把后续转发给后端的请求误判为 HTTP，Secure 的判断逻辑也会完全失效。

先保护会话凭证：三个属性分别挡什么

不少人会把 Cookie 安全属性当成互不相关的独立开关，很容易出现漏配。它们管控的是完全不同的攻击路径：HttpOnly 限制页面脚本读取，SameSite 限制跨站请求自动携带，Secure 限制 Cookie 在明文 HTTP 通道里发送。单个属性配置正确，不代表另外两条风险路径已经被封堵。

登录态通常不需要交给前端 JavaScript 直接使用，因此建议先从最小必要组合开始配置：

http.SetCookie(w, &http.Cookie{
    Name:     "session_id",
    Value:    sessionID,
    Path:     "/",
    HttpOnly: true,
    Secure:   requestIsHTTPS(r),
    SameSite: http.SameSiteLaxMode,
    MaxAge:    int((8 * time.Hour).Seconds()),
})

这里的 Value 必须是不可被猜解的会话标识，不能直接存用户 ID、邮箱或者明文 JSON 内容。Cookie 属性解决的只是浏览器侧的发送边界，完全不能替代服务端对会话状态、过期时间和主动撤销能力的检查。

跨站请求怎么收口：SameSite 先按业务关系选

SameSite=Lax 是绝大多数后台和普通 Web 业务登录态的默认安全起点。它允许部分顶级跳转场景带上 Cookie，但会大幅减少跨站表单、跨站脚本请求自动携带登录态的机会。如果你的站点确实需要被其他站点嵌入，或者支付回调这类场景必须依赖跨站 Cookie，再去落地 SameSite=None 的相关配置。

None 必须同时配合 Secure 一起启用，否则当前主流版本的浏览器会直接拒绝这组配置。此时不能只修改 Go 代码，还要提前梳理所有允许的嵌入方、回调路径和异常失效处理逻辑；跨站 Cookie 权限放得越宽，CSRF 防护就越不能只依赖浏览器的默认策略。

func sessionCookie(id string, crossSite bool, https bool) *http.Cookie {
    mode := http.SameSiteLaxMode
    if crossSite {
        mode = http.SameSiteNoneMode
    }
    return &http.Cookie{
        Name:     "session_id",
        Value:    id,
        Path:     "/",
        HttpOnly: true,
        Secure:   https,
        SameSite: mode,
    }
}

如果只是前后端分离但业务仍属于同一站点，不要因为前端域名和API域名不一样就直接选 None。先确认站点归属关系、请求触发方式和浏览器实际的 Cookie 发送结果，再决定是否需要放宽跨站策略。

反向代理后 Secure 怎么判断：只信明确的入口边界

常见的线上部署架构是浏览器到 Nginx 或者云负载均衡走 HTTPS，代理转发到 Go 服务的内部链路走 HTTP。此时 Go 服务侧看到的 r.TLS 可能为空，但用户侧的连接仍然是全程加密的。如果直接用 r.TLS != nil 来判断要不要给 Cookie 加 Secure 属性，很容易在生产环境把登录 Cookie 写成非 Secure 模式。

更稳妥的做法是只接受可信入口转发过来的专属标记，在应用层入口统一把这个标记转换成布尔值来判断用户侧的连接协议。不能把任意外部客户端传过来的 X-Forwarded-Proto 当成可信事实：

func requestIsHTTPS(r *http.Request) bool {
    if r.TLS != nil {
        return true
    }
    // 只有请求已经经过受信任的边缘代理时，才允许读取该标记。
    if !trustedProxy(r) {
        return false
    }
    return strings.EqualFold(r.Header.Get("X-Forwarded-Proto"), "https")
}

trustedProxy 不能只靠“请求头里存在某个字段”来实现，必须结合负载均衡的网络入口、受控网段或者网关注入的可信上下文来完成。应用和代理之间如果没有明确的信任约定，宁可让 HTTPS 判断失败并抛出告警，也不能给外部用户留下伪造标记的空间。

属性写上了还不够：用响应头和浏览器行为验收

验收环节先抓取登录接口的响应包，确认返回头符合预期，重点检查属性是否真的透传到了浏览器侧：

Set-Cookie: session_id=opaque-value; Path=/; Max-Age=28800; HttpOnly; Secure; SameSite=Lax

• 在 HTTPS 页面打开开发者工具的 Application/Storage 面板，确认 Cookie 的 HttpOnly、Secure 和 SameSite 三个字段的取值和预期一致。
• 在控制台尝试读取 document.cookie，不应出现 session_id。
• 从外部站点发起合法的跨站表单测试，检查敏感写操作是否仍然要求校验 CSRF Token 或者 Origin 字段。
• 分别从直连应用、测试代理和生产入口三种路径登录，确认三类环境不会因为协议判断逻辑差异生成不一样的 Cookie 属性。

常见问题：Cookie 安全属性怎么核对

HttpOnly 能防止 XSS 攻击吗？

不能。它只是减少了脚本直接读取 Cookie 的机会，XSS 漏洞仍然可以借助当前已登录的会话态发起页面操作，所以输出编码、CSP 配置和输入校验这些基础防御工作还是不能省。

Secure 能防止会话被伪造吗？

不能。Secure 主要用来限制 Cookie 不会通过明文 HTTP 通道发送；会话 ID 的随机性、服务端存储机制和定期轮换策略，才是决定凭证是否容易被猜中或者长期复用的核心因素。

SameSite=Lax 能替代 CSRF Token 吗？

不建议直接完全替代。针对跨站业务、旧版本浏览器、特殊跳转场景和高风险写操作，仍然要校验 CSRF Token 或者 Origin 字段，同时把所有校验失败的请求完整记录下来留作审计。

落地检查清单

可以把 Cookie 安全检查收敛成四个问题：这个 Cookie 值是否必须允许脚本读取？跨站请求是否确实需要携带这个 Cookie？用户到可信入口的连接是否全程使用 HTTPS？代理转发标记是否来自明确的信任边界？四个问题都得到明确答案之后，再把对应的校验逻辑写进集成测试，后续改网关配置或者调整域名规则时，就不容易悄悄退化安全配置。