新版本chrome浏览器带来的跨域请求cookie丢失问题

7 篇文章 0 订阅
2 篇文章 0 订阅

A cookie associated with a cross-site resource at http://weibo.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies

今天线上业务的跨域接口请求莫名的出现问题,经深入排查,发现新版本的chrome浏览器(80版本之后)对cookie的校验更加严格,SameSite属性默认值由None变为Lax,因此可能会对线上业务带来问题特此与大家同步一下今天的发现,存在跨域接口调用业务的小伙伴可能需要关注。

在这里插入图片描述
chrome升级到80版本之后(准确的说是78版本之后,灰度测试,如上图,即也可能存在同一版本不同人的浏览器表现不同),cookie的SameSite属性默认值由None变为Lax,该问题的讨论可参考:https://github.com/google/google-api-javascript-client/issues/561

在Lax模式下,以下类型请求将受影响
在这里插入图片描述
此时可以尝试显式声明 Cookie 的SameSite属性为None,并设置Secure (不然无效)。

更多关于cookie SmaeSite属性的介绍可参考: https://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

另外,新版本chrome的devtool中的提示及指引文档如下:

以上问题由浏览器版本升级导致,很突然,如果线上遇到了,短时间不易定位问题,不容易往浏览器限制这方面想,今天也是花了一定时间才确定问题,特此整理下,希望帮助大家快速处理同类问题,随着陆续越来越多的用户浏览器版本升级上来,问题会逐渐暴露,最好能提前做好准备。

扩展阅读:SameSite 属性是什么

Cookie 的SameSite属性用来限制第三方 Cookie,从而减少安全风险。

它可以设置三个值。

  • Strict
  • Lax
  • None
Strict

Strict最为严格,完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie。换言之,只有当前网页的 URL 与请求目标一致,才会带上 Cookie。

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规则过于严格,可能造成非常不好的用户体验。比如,当前网页有一个 GitHub 链接,用户点击跳转就不会带有 GitHub 的 Cookie,跳转过去总是未登陆状态。

Lax

Lax规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

导航到目标网址的 GET 请求,只包括三种情况:链接,预加载请求,GET 表单。详见下表。

请求类型示例正常情况Lax
链接<a href="..."></a>发送 Cookie发送 Cookie
预加载<link rel="prerender" href="..."/>发送 Cookie发送 Cookie
GET 表单<form method="GET" action="...">发送 Cookie发送 Cookie
POST 表单<form method="POST" action="...">发送 Cookie不发送
iframe<iframe src="..."></iframe>发送 Cookie不发送
AJAX$.get("...")发送 Cookie不发送
Image<img src="...">发送 Cookie不发送

设置了StrictLax以后,基本就杜绝了 CSRF 攻击。当然,前提是用户浏览器支持 SameSite 属性。

None

Chrome 计划将Lax变为默认设置(80版本已实施)。这时,网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效

下面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

如对您有帮助,不妨点一波关注~

Chrome浏览器从版本108开始,对于跨域问题做出了一些改变。在此之前,浏览器是严格限制跨域请求的,但是自从Chrome 108版本之后,浏览器默认支持通过一些新的方法来解决跨域问题。 首先,Chrome 108引入了新的CORS(跨域资源共享)规范,它通过在服务器的响应头中添加一些额外的字段来指示浏览器是否允许跨域请求。如果服务器返回的响应中包含了'Access-Control-Allow-Origin'字段且值为请求的域名,则浏览器将允许该跨域请求。这样,网页开发者可以通过在服务器端设置正确的响应头来解决跨域问题。 其次,Chrome 108还引入了一种新的跨域请求方式,即Fetch API。Fetch API是一种用于代替传统的XMLHttpRequest对象的新的网络请求API,它默认支持跨域请求,并且提供了一系列的方法和选项来处理跨域问题。通过使用Fetch API,网页开发者可以更灵活地发送和处理跨域请求。 此外,Chrome 108还提供了一些其他的跨域解决方案。例如,开发者可以在服务器端设置CORS策略,通过细粒度的配置来控制哪些域名可以进行跨域请求。另外,Chrome 108也支持通过在请求中添加'Access-Control-Allow-Credentials'字段来允许跨域请求携带认证信息。 综上所述,Chrome浏览器108版本以上对跨域问题做出了一些改进和优化。通过使用CORS规范、Fetch API以及其他解决方案,网页开发者可以更轻松地处理跨域请求,并提供更好的用户体验。
评论 17
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小白旗

您的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值