今天看了一道面试题，关于cookie中的SameSite属性，但是由于自己开发经验较少，所以并没有涉及到。所以我去查了一些文章，说一下自己对于cookie的SameSite属性的理解。
一、写在头部
我们在处理CSRF攻击的时候，常常使用的解决方案是1、判断http的Referer属性,2、设置csrf token，3、在http中设置自定义字段保存token。我们使用如上三种方式就可以解决CSRF的攻击。今天我们所说的cookie中的SameSite属性也是可以解决CSRF攻击的。
我们都是HTTP是没有状态的，然后为了保存状态，后来网景公司发明了cookie用来记录用户的状态信息。但是存在一个弊端，就是我们网站A的cookie可以作为第三方网站的cookie去使用。这样就造成了CSRF的漏洞。SameSite就可以限制第三方cookie的使用。
二、SameSite的属性值
SameSite可以设置为三个属性strict,Lax,None，接下来我们将从三个属性分别去介绍。
属性一：strict属性：该属性表示表示完全禁止第三方cookie,也就是在跨站时，均不会携带cookie,只有当前站点的url和访问的站点的url一致时，才能携带cookie。但是我们此时想一种情况，比如说当前站点A存在一个链接，链接到gitte网站，如果我们之前已经登录了gitte网站的话，则我们再次访问该网站时应该是处于登录状态的。但是我们对当前站点cookie设置了SameSite属性为strict值，所以当前跳转链接并不会携带cookie，所以我们的信息无法得到认证，此时就需要重新登录。

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

属性二：Lax:该属性比strict的属性要宽松一些，其允许我们在跨站使用get请求时携带cookie。

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

导航到目标网址的get请求主要包括三种，链接，预加载，get表单。具体如下所示。

将SameSite设置为Strict和Lax时，就可以防止CSRF攻击了。
属性三：None属性：chrome默认将Lax设置为默认值，此时我们可以更改samesite的值，将其设置为none,此时必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。
下面是无效的：

Set-Cookie: widget_session=abc123; SameSite=None

下面是有效的：

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

三、使用场景
如果我们的网站是一个管理系统，或者是用户较少，经常采用输入网址的方式或者从浏览器的收藏夹中打开该网站时，我们可以使用strict。如果我们做的一些网站例如说博客，当我们在其他站点设置跳转的时候，如果我们使用strict的话，就会设置重新登录，此时我们可以将SameSite的值设置为Lax。
如果我们的网站中存在一些iframe嵌套，如果使用strict和Lax就不会携带cookie进行身份验证，此时如果需要身份验证登录，任然需要再次登录。所以此时就能使用strict或Lax属性值。
四、缺点
SameSite仍然存在一些缺点：首先就是不支持子域，如果从主域跳转到子域，也不会携带cookie,此时就会重新登录。第二就是浏览器的兼容性不是很好，很多浏览器不支持该属性。