设置其他域名cookie

设置其他域名的 Cookie 是 Web 开发中典型的< b>跨域通信需求，但浏览器基于< b>同源策略与< b>Cookie 安全模型，不允许当前网页直接为任意无关域名写入 Cookie。根据 RFC 6265，Cookie 必须归属于生成它的< b>宿主域；服务端在 Set-Cookie 响应头中设置的 Domain 属性，也只能是该服务器主域名本身或其父级域名。若通过 document.cookie 在 JavaScript 中操作，则只能修改当前文档所在域名的 Cookie，无法指定其他域名。

一、基于目标域名服务端写入

最可靠的方式是让浏览器向目标域名发送 HTTP 请求，由目标域名的服务端在响应中通过 Set-Cookie 头写入 Cookie。例如站点 A 需要站点 B 设置 Cookie，可将用户重定向到 B 域名，或从 A 页面通过 fetch 或 XMLHttpRequest 发起对 B 接口的请求。使用 AJAX 跨域模式时，请求需要设置 withCredentials=true 或 credentials:"include"，同时服务端必须允许 CORS，返回 Access-Control-Allow-Credentials: true，且不能将 Access-Control-Allow-Origin 配置为 *。

二、通过父域共享 Cookie

如果两个业务域名属于同一个注册域下的不同子域，如 app.example.com 与 api.example.com，则可以在 Set-Cookie 中使用 Domain=.example.com。这样 Cookie 会作用在整个 example.com 父域及其所有子域。此方式是合法的父子域共享，而不是真正写入另一个无关域名。

三、使用重定向或 SSO 流程

在跨域登录与统一身份认证场景中，通常让用户从站点 A 重定向到站点 B 的认证接口，B 验证身份后在自己的域名下设置 Cookie，再把用户送回 A。这类流程兼容 OAuth 2.0 与 OpenID Connect，是设置其他域名 Cookie 的成熟方案。因为浏览器此时直接访问 B 域名的文档，B 的响应头 Set-Cookie 会被浏览器正常接受。

四、iframe 嵌入对端域名页面

如果页面使用 iframe 加载另一个域名，则 iframe 内目标域名文档的响应也能在其自身域名下写入 Cookie；iframe 内脚本也可使用 document.cookie 设置同域 Cookie。但需要注意，iframe 与嵌入它的顶层页面属于跨站上下文，此时写入的 Cookie 属于 第三方 Cookie。当前主流浏览器默认拦截第三方 Cookie，即使使用 SameSite=None; Secure 也可能被 Safari ITP、Firefox ETP、Chrome 隐私沙箱策略阻止，因此该方法已不推荐作为唯一方案。

五、通过 CNAME 映射域名

若你同时拥有目标域名的 DNS 控制权，可以将目标域名通过 CNAME 映射到自己的服务器。例如将 cdn.other-domain.com 解析到你的服务器，浏览器请求该域名时实际由你的服务器应答，服务端返回的 Set-Cookie 可以合法写入该域名。此方法常用于统计平台、广告跟踪和聚合服务。

六、旧式子资源方式

早期很多站点使用 script 或 img 标签向目标域名发起 GET 请求，并在响应中植入 Cookie。这种方式可以通过响应头收到 Set-Cookie，但同样属于跨站上下文中的第三方 Cookie 植入，已受到主流浏览器的严格限制，不能作为稳定的业务方案。

七、关键属性与安全限制

跨域设置 Cookie 时还必须考虑以下属性：HttpOnly 可防止 JavaScript 读取 Cookie，降低 XSS 攻击风险；Secure 要求 Cookie 只能通过 HTTPS 连接发送；SameSite 控制跨站请求携带 Cookie 的行为，其中 Strict 表示严格同站发送，Lax 仅允许顶级导航携带，None 必须配合 Secure 使用。现代浏览器会为缺少 SameSite 属性的 Cookie 默认应用 Lax 策略。

结论：不存在既不需要访问目标域名服务器、也不拥有该域名控制权，就能直接为其他域名设置 Cookie 的通用方案。任何允许第三方任意写入 Cookie 的机制都会形成严重安全漏洞。实际项目中应从 服务端 Set-Cookie、父域共享、跨域重定向、iframe 或 CNAME 中选择与场景匹配的方案，并始终遵循浏览器最新的隐私与安全策略。