flawopen.com/CSRF/SameSite Cookie
SameSite=Strict 能取代 CSRF 令牌吗？
SameSite=Strict 是浏览器为来自其他站点的 Cookie 认证请求提供的强力防护层，但不是通用的 CSRF 防御。不同 origin 的相邻子域仍属于同一站点；不执行该属性的客户端也得不到保护。威胁模型要求时，应保留 CSRF 令牌或其他请求来源防御。
SameSite 实际做什么
SameSite=Strict Cookie 不会随跨站请求发送，包括其他站点向你的应用自动提交表单这一经典 CSRF 模式。这样浏览器就不会在该场景中自动附带会话 Cookie。SameSite 按站点而非 origin 判断：来自相邻子域的请求仍可能属于 same-site，因此 Strict 无法防御被攻陷或不可信的相邻主机。用户点击外部链接进入站点时，Strict 也可能不发送 Cookie，导致用户暂时未登录。
仍有哪些局限
如果应用把 bearer token 显式放入 Authorization 请求头，SameSite 不会控制该请求头。浏览器自动发送 Cookie 的机制不同。但这并不意味着所有此类设计都安全：还要评估其他机制是否会自动附带凭据，并防止令牌被窃取或滥用。
显式设置 SameSite=Lax 时，Cookie 会随 same-site 请求以及使用安全方法（如 GET）的跨站顶层导航发送；跨站子请求和使用非安全方法的导航不会携带该 Cookie。省略属性时使用用户代理的默认值。在 Chromium 中，该默认值与显式 Lax 不同：当前实现允许部分未显式设置属性的 Cookie 在创建后最多 2 分钟内随跨站非安全顶层请求发送（Lax-allowing-unsafe）。不要将这种浏览器兼容行为当作 CSRF 防护。请显式设置预期属性、测试支持的客户端，并确保安全方法不会触发状态变更。
SameSite 由浏览器执行。不支持或不遵守该属性的客户端不会获得保护。请核对应用支持的客户端，并将 SameSite 作为纵深防御的一层，配合适当的 CSRF 令牌、Origin 验证或其他主要防御。
常见问题
请参阅安全方法的专门说明。不要让状态变更操作通过 GET 等安全方法访问；安全方法的语义是不改变服务器状态。