在嵌入三方应用并使用三方登录时经常会遇到iframe中使用cookie的场景。比如网站嵌入了第三方评论模块，评论模块登录会打个一个iframe，iframe会加载相应的登录页面，我们在iframe中登录完成后，登录态写入cookie，关闭iframe后，三方登录模块会发起请求获取登录数据，完成登录操作。在以前或许一切都会运行正常，但是在各个新版的浏览器（Chrome等）iframe不会向服务器发送cookie了。
这个问题也是困扰我挺久的，主要是不久前iframe还是能够正常读取cookie并发送给服务器。现在由于部分浏览器的安全性能升级，iframe在未做一些配置之前是不会读取并发送cookie了。
解决方案
Set-Cookie: session=your_session; SameSite=None; Secure
你需要修改服务器，将cookie设置为attributeSameSite = None，同时还包括属性Secure。
原因
现在问题已经解决了，我们可以看下为什么会引起这个问题
同源和三方Cookie
与当前站点的域匹配的cookie被称为第一方cookie。来自当前站点以外的域的cookie称为第三方cookie。
长期以来，两种cookie均一视同仁：每次您请求一个URL时，该URL的所有cookie都随请求一起发送。与此行为相关的各种问题：
- 1. 允许跨站点请求伪造（CSRF）攻击。
- 2. 给请求增加开销，发送可能不需要的东西。
- 3. 可用于跟踪多个站点上的用户活动
通过SameSite属性说明Cookie的使用情况
RFC6265bis为cookie定义了一个新属性：SameSite。此属性允许你声明你的cookie是否应限制在第一方或同一站点上下文中。可能的值：
None：Cookie也将在第三方环境中发送。Strict：Cookie只会在第一方上下文中发送（当浏览器的URL栏中的域与您的Cookie域匹配时）。Lax：Cookie将在第一方上下文中发送，并与顶级导航一起发送。使用该Strict策略，导航到顶级URL时不会发送cookie。Lax从RFC6265bis中提取的值解决方案的示例
考虑一种情况，用户在MegaCorp
Inc的网络邮件提供商“ https://example.com/ ”上阅读电子邮件。他们可能希望
单击通过电子邮件发送的链接到“ https://projects.com/secret/
project”向他们显示他们有权
查看的秘密项目，但是如果“ projects.com”已将其会话cookie标记为
“ SameSite = Strict”，则此跨站点导航将不会将其
与请求一起发送。 .com”会显示404错误，以避免
泄露机密信息，并且用户会非常困惑。
默认值更改
如果未设置Cookie，则SameSite浏览器必须猜测您的意图。浏览器曾经默认None设置为未设置属性，但是这种行为正在改变。
IETF提案“渐进式更好的Cookies”提出了两个重要更改：
- 1. 没有
SameSite属性的Cookies将被视为SameSite=Lax。 - 2. Cookie
SameSite=None也必须指定Secure，表示它们需要安全的上下文。
Chrome从84版开始实施此默认行为，其他浏览器也将在不久的将来使用。
cookie安全
解决方案的第二部分：Secure属性。
当在HTTP响应中向用户发送新cookie时，应用服务器可以设置此属性。安全标志的目的是防止由于以明文形式传输cookie而导致未经授权的各方查看cookie。
当请求进入HTTPS页面时，支持安全标志的浏览器将仅发送带有安全标志的cookie。
因此，除了 SameSite=None和之外Secure，iframe中使用的URL必须是以https开头的安全URL。
总结
SameSite何时用Strict，Lax或None为值：
Lax：选择正确显示网站所需的Cookie。正如我们前面所看到的，当用户到达来自另一个站点的链接后的顶级URL时，应将此值用于所需的任何cookie。Strict：对于与Cookie相关的用户执行的操作非常有用，并且不会影响网站的显示。None：在第三方上下文中何时需要Cookie可供我们所有应用程序的URL使用（无论是否为顶级）的选择。示例：Youtube的登录Cookie设置有此属性，以便在您看到与youtube本身不同的任何网站中嵌入的视频时都可以发送。
