Go Cookie SameSite 配置在跨站请求中的边界

我在调试“前端请求明明发出去了，Go 服务却读不到 session Cookie”时，最容易先改 CORS。后来把链路拆开才发现，SameSite、浏览器的 credentials 和服务端 CORS 是三层规则。Go 只负责生成 Set-Cookie，浏览器再决定请求时是否携带它。

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

先分清跨站和跨源

https://app.example.com 与 https://api.example.com 是不同 origin，但通常仍属于同一个 site；如果协议、可注册域等站点条件发生变化，才进入 SameSite 的跨站判断。反过来，前端即使只是跨源调用，也可能被 CORS 拦住，但这不是 SameSite 在起作用。

所以排查顺序应是：先看请求是否跨站，再看请求是不是顶层安全导航，最后才决定 Cookie 属性。不要把“加了 Access-Control-Allow-Origin”当成“Cookie 一定会发送”。

SameSite 三种策略分别挡住什么

Go 的 http.SameSite 有四个公开模式：Default、Lax、Strict、None。其中 Default 在序列化时不输出 SameSite 属性，最终默认行为由浏览器决定；不要把它当成 Go 内部的 Lax 开关。

我的取舍是先用 Lax；只有业务明确依赖 iframe、第三方嵌入或跨站接口携带会话，才改为 None，并同步检查 HTTPS、CSRF 防护和浏览器限制。

在 Go 中把配置写成明确的策略

下面的函数把“是否需要跨站 Cookie”作为部署配置，而不是从请求头临时推断。这样上线时能审查策略，避免攻击者通过输入影响 Cookie 属性。

package session

import "net/http"

func writeSession(w http.ResponseWriter, crossSite bool) {
	// 普通网页登录优先 Lax，兼顾跨站链接跳转和会话隔离。
	sameSite := http.SameSiteLaxMode
	if crossSite {
		// None 允许跨站携带；生产环境必须通过 HTTPS 发送 Secure Cookie。
		sameSite = http.SameSiteNoneMode
	}

	http.SetCookie(w, &http.Cookie{
		Name:     "session",
		Value:    "opaque-session-id",
		Path:     "/",
		Secure:   true, // 防止 Cookie 通过明文 HTTP 发送。
		HttpOnly: true, // 阻止脚本直接读取会话值。
		SameSite: sameSite,
	})
}

这里的 Secure 不只是给 None 凑条件：会话 Cookie 本身也应避免走明文链路。开发环境若使用 HTTP，应通过本地 HTTPS 或明确的开发配置处理，不能把生产代码改成永久关闭 Secure。

Go 配置、浏览器过滤与 CORS 要分层排查

1. 先看响应：确认 Go 返回的 Set-Cookie 中确实出现预期的 SameSite、Secure、Path 和 Domain。
2. 再看浏览器策略：若是跨站 fetch、iframe 或 POST，Lax/Strict 可能在请求发出前就过滤 Cookie；改 CORS 无法绕过这一层。
3. 再看 Fetch：跨源 fetch 需要调用方使用 credentials: "include"，否则浏览器不会按跨源凭据流程处理 Cookie。
4. 最后看 CORS：服务端要返回具体的 Access-Control-Allow-Origin，并在需要时返回 Access-Control-Allow-Credentials: true；不能把允许凭据和通配符 origin 混用。

这四步能解释一个常见现象：响应里 Cookie 已经成功设置，但后续请求没有 Cookie 头。问题可能发生在浏览器的 SameSite 过滤，也可能发生在 fetch 凭据选项；服务器甚至还没机会参与。

上线前用场景表做回归

• 同站页面访问 API：Lax 通常足够，确认 Path 覆盖接口路径。
• 外站点击链接进入登录页：Lax 可保留较好的跳转体验，Strict 要重点回归登录态。
• 外站 iframe 或跨站 POST：不要直接把会话改成 None；先确认是否真的需要 Cookie，再补 CSRF token、HTTPS 和具体 CORS 配置。
• 子域之间调用：先判断是否只是跨源，再检查 Domain、CORS 和 fetch credentials，不要只改 SameSite。

延伸问答

Go 的 SameSiteDefaultMode 等于 SameSite=Lax 吗？

不等于。Go 会省略 SameSite 属性，浏览器可能采用自己的默认策略；要表达明确的 Lax，应直接使用 http.SameSiteLaxMode。

设置 credentials include 后为什么仍然没有 Cookie？

它只解决 fetch 的凭据意图，不能突破 SameSite、Secure、Domain、Path 或浏览器第三方 Cookie 限制；应按响应、浏览器过滤、fetch、CORS 的顺序排查。

SameSite=None 是否代表任何跨站请求都安全可用？

不是。它扩大了 Cookie 的发送范围，必须配合 Secure、HTTPS、CSRF 防护和最小化 Domain/Path 使用。