net/http Cookie SameSite 属性的跨站请求配置

如果 Go 服务把会话 Cookie 设置成 SameSite=Strict，跨站页面发起的请求通常不会带上它；如果改成 SameSite=None，浏览器又会要求 Cookie 同时带有 Secure。因此“跨域请求没有登录态”很少只是 Go 结构体少写一个字段，还要同时检查浏览器凭据模式和服务端 CORS 响应头。

官方文档：https://pkg.go.dev/net/http

结论：先判断请求是同站还是跨站，再选择 SameSite；只有明确需要跨站携带 Cookie 时才使用 None，并配合 HTTPS、浏览器 credentials 和精确的 CORS 允许源。

先分清 site 和 origin

SameSite 关注的是“站点”边界，不能简单等同于“端口不同就是跨站”。浏览器会根据站点、协议和请求上下文决定 Cookie 是否属于跨站发送；而 CORS 关注的是一个源能否读取另一个源的响应。两个概念经常同时出现，但不是同一个开关。

例如前端页面从 https://app.example.com 请求 https://api.example.com，它们可能仍属于同一站点，但属于不同 origin，读取响应仍会受到 CORS 规则影响。如果页面来自完全不同的站点，则 Cookie 的 SameSite 规则也会参与判断。

用 Cookie.SameSite 表达三种发送策略

Go 的 http.Cookie 提供 SameSiteDefaultMode、SameSiteLaxMode、SameSiteStrictMode 和 SameSiteNoneMode。Default 表示不主动输出 SameSite 属性，实际默认行为由浏览器决定；Lax 允许有限的跨站顶层导航；Strict 更严格；None 表示允许跨站携带，但浏览器要求同时使用 Secure。

package main

import "net/http"

func writeSessionCookie(w http.ResponseWriter, crossSite bool) {
    sameSite := http.SameSiteLaxMode
    if crossSite {
        // 跨站会话必须显式选择 None，并让浏览器只在 HTTPS 下发送。
        sameSite = http.SameSiteNoneMode
    }

    http.SetCookie(w, &http.Cookie{
        Name:     "session_id",
        Value:    "opaque-session-value",
        Path:     "/",
        HttpOnly: true,
        Secure:   crossSite,
        SameSite: sameSite,
    })
}

上面的 crossSite 只是示例决策结果，生产代码不应直接相信客户端传来的布尔值。会话 Cookie 通常优先使用 Lax 或 Strict；只有嵌入式内容、跨站前端与 API 的确需要共享会话时，才把 None、Secure 和 HTTPS 作为一组配置。

跨站 fetch 还需要凭据和 CORS 同时成立

即使 Cookie 的 SameSite 配置正确，浏览器也不会因为服务端设置了 Cookie 就自动把它附加到跨源 fetch。前端请求需要显式使用 credentials: "include"，服务端则必须返回具体的 Access-Control-Allow-Origin，并返回 Access-Control-Allow-Credentials: true。带凭据时不能把允许源写成通配符。

package main

import "net/http"

func apiHandler(w http.ResponseWriter, r *http.Request) {
    origin := r.Header.Get("Origin")
    if origin == "https://app.example.com" {
        // 允许的来源要使用白名单，避免把带会话的响应开放给任意站点。
        w.Header().Set("Access-Control-Allow-Origin", origin)
        w.Header().Set("Access-Control-Allow-Credentials", "true")
        w.Header().Add("Vary", "Origin")
    }

    if r.Method == http.MethodOptions {
        // 预检只声明实际需要的方法和请求头，然后结束本次请求。
        w.Header().Set("Access-Control-Allow-Methods", "GET, POST, OPTIONS")
        w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
        w.WriteHeader(http.StatusNoContent)
        return
    }

    w.WriteHeader(http.StatusNoContent)
}

前端对应的请求可以写成：

fetch("https://api.example.com/profile", {
  // 允许浏览器在跨源请求中携带符合条件的 Cookie。
  credentials: "include",
})

按场景选择模式并排查边界

如果请求仍然没有登录态，按这个顺序拆查：Cookie 响应是否真的包含期望的 SameSite 和 Secure；页面是否通过 HTTPS；fetch 是否使用 include；服务端是否返回了与 Origin 完全匹配的允许源；OPTIONS 预检是否被正确处理；最后再检查 Domain、Path、过期时间和浏览器对第三方 Cookie 的额外限制。

SameSite 只能减少一部分跨站请求风险，不能替代 CSRF Token、Origin/Referer 检查或避免用 GET 执行状态变更。特别是把会话开放给跨站前端时，更要把“能携带 Cookie”和“允许读取响应”看成两层独立权限。

相关问题

SameSite=None 为什么必须配 Secure？现代浏览器通常要求跨站 Cookie 同时带 Secure，意味着只能通过 HTTPS 发送；本地调试应使用与浏览器策略相容的 HTTPS 环境或明确的开发配置。

Allow-Origin 写成星号后为什么仍然失败？带凭据的 CORS 响应不能使用 * 作为允许源，需要返回具体来源，并让请求端使用 credentials: "include"。

SameSite 能完全防住 CSRF 吗？不能。它是浏览器层面的限制之一，状态变更接口仍应使用 CSRF Token 或其他服务端校验，并避免用 GET 修改数据。