万维网文化属性之一是开放共识。这使得许多人创造自己的内容和应用程序成为可能。然而这也带来了一些安全和隐私风险。跨站请求伪造攻击（Cross-site request forgery attack-csrf）制造依赖于那些cookie将会被携带在针对指定域名的请求中,而不论这些请求具体由谁触发。举个例子，当你访问了evil.example并且它可以触发your-blog.example的请求，那么浏览器将会很乐意携带上关联的cookie。如果你的博客对这些请求的验证不够仔细那么evil.example可以触发删除和添加内容的任何操作。
用户现在更加清醒的意识到cookie怎样被用来跟踪他们在不同页面的活动轨迹。然而直到现在仍然没有一种明确的方式表明对cookie本来用意。你的promo_showncookie本应该只被用在自有站点环境下，而嵌入到第三方站点的组件所携带的会话cookie是被用来保持会话状态。
使用SameSite明确表明cookie的用途SameSite属性的引入（定义在）允许你表明你的cookie被用在第三方或者自己的站点环境下。明白站点的确切意义将会大有裨益。站点是域名后缀和它前面部分的混合。例如，域名站点是web.dev域名站点的一部分。
关键词same-site如果用户在发起了一个向static.web.dev的图片请求这是一个same-site请求。
public suffix list定义了这些，不仅是像.com这样的顶级域名也包括像github.io这样的域名。这使得your-project.github和my-project.github被认为为不同的站点。
关键词cross-site如果用户在your-project.github.io站点发起了一个向my-project.github.io的请求，这是一个cross-site请求。
在cookkie中引入SameSite属性三种控制这种行为的方式。你可以不指定指定这个属性，或者通过使用Strict或Lax来限制cookie只在same-site请求下携带。
如果你设置SameSite属性为Strict,那么你的cookie将会只在自有环境下发送。在用户看来，那个cookie只会在匹配当前显示在地址栏的站点时才会被发送。所以，假设Promo_showncookie如下设置：
Set-Cookie: promo_shown=1; SameSite=Strict那么当你的用户在你的站点上是，cookie将会如预期被发送。然而当从一个指向你站点的引用链接，详细地说当从另一个站点或者从通过一个朋友发给你的一个链接，在初始请求里并不会这个cookie并不会被发送。当你拥有一些关联后置于初始导航你站点功能的cookie的情形下，例如修改密码或者下订单的情形下，这是极其有用的，但是对于promo_shown这个功能限制太多。如果你的用户通过链接进入你的站点，他们希望cookie能被发送，这样他们的设置能够生效。
当你的用户初始导航到你的网站上时cookie将会被发送，这就是SameSite=Lax的使用场景。让我们继续回顾那个引用小猫图片的例子，那个例子中其他站点正在引用你的内容。他们直接使用你的小猫图片并且提供了一个指向你的原始文章的链接地址。
<p>Look at this amazing cat!</p> <img src="http://blog.example/blog/img/amazing-cat.png" /> <p>Read the <a href="http://blog.example/blog/cat.html">article</a>.</p>cookie这样设置：
Set-Cookie: promo_shown=1; SameSite=Lax当浏览者在其他人的博客上请求amzing-cat.png，cookie将不会被发送。然而当读者通过一个点击一个指向你站点cat.html的链接时，cookie将会被发送。这样的话，使得Lax成为设置影响网站外观cookie的好选择而Strict将会对用户那些关联到当前操作的cookie极其有用。
注意Strict和Lax对于你的站点安全都不是一个完整的解决方案。cookie将会作为用户输入的一部分,你需要像对待其他用户输入一样。意味着，需要对这些输入进行脱敏和验证。绝对不要将服务端的重要数据存储在cookie中。
最后还有一个不设置这个值的默认方式，那么cookie将会在所有上下文情形下被发送。在最新的草案中这种方式被SameSite=None这个新值明确表达。这表明你可以通过设置SameSite=None来明确表明你希望cookie在所有第三方上下文环境下被发送。
!(None Lax Strict)[https://webdev.imgix.net/samesite-cookies-explained/samesite-none-lax-strict.png]
通过None，Lax和Strict来明确表明cookie的使用上下文
★ 如果你提供了供其他网站使用的服务，例如嵌入式组件、嵌入式多媒体内容、联合程序、广告、跨站登陆那么你需要使用None来明确表明的意图。
未设置SameSite属性默认行为的变化尽管SameSite属性得到广泛支持，很不幸的是并没有很广泛的被开发者使用。cookie在所有地方都会被发送的开放默认行为使得所有场景都能正常工作，但是这样提高了用户受到CSRF和意外信息泄漏的风险指数。为了号召开发者明确表明他们的意图并且提供用户更高的安全使用体验，IETF发布了一个提议，Incrementally Better Cookies 提供了两项关键改进：
那么没有设置SameSite属性的cookie将等同设置了SameSite=Lax
cookie设置SameSite=None必须同时设置Secure,这意味着需要在更安全的环境下传输。