首页/安全/漏洞与攻击面速查/SameSite Cookie 属性配置
Web 漏洞原理与防护55 条

SameSite Cookie 属性配置

SameSite 控制 Cookie 在跨站请求中的发送:Strict 严格、Lax 为现代浏览器默认(顶层导航 GET 放行)、None 必须配合 Secure;它明显收窄 CSRF 面,但需评估跨站跳转场景。

漏洞与攻击面速查安全更新于 2026-10-13

SameSite 是什么

SameSite 是 Cookie 的一个属性,用来控制浏览器在跨站请求中是否携带该 Cookie。它把『是否发送』的判定从服务端挪到了浏览器端,因此能明显收窄 CSRF 面,但不改变服务端仍需校验请求来源与令牌的事实。现代浏览器已把未声明该属性的 Cookie 按 Lax 处理,站点行为会随浏览器策略变化,需要显式声明而不是依赖默认值。

基本信息

属性取值Strict / Lax / None
浏览器默认Chrome 等已将未声明值按 Lax 处理
None 前提必须同时带 Secure,否则 Cookie 被浏览器拒绝
作用范围仅影响浏览器发送行为,服务端校验仍不可省略

取值与行为

取值跨站发送行为适用场景
Strict跨站请求一律不发送高敏感管理后台
Lax顶层导航 GET 发送,其余不发送通用站点默认值
None总是发送,必须配 Secureiframe 嵌入、跨站单点登录回调
未声明按浏览器默认(趋同 Lax)不推荐:行为随浏览器版本漂移

典型使用场景

  • 自建管理后台的会话 Cookie 用 Strict,避免从外部链接直接带会话进入
  • 电商类站点用 Lax:既防跨站表单提交,又保证从邮件与搜索进入时保持登录态
  • 需要嵌入第三方站点的登录组件用 None + Secure,并单独评估第三方可信度
  • 排查『用户点邮件链接后需要重新登录』问题时,先看是否被 Strict 拦掉了跨站导航
  • 做安全整改基线时把 SameSite 与 HttpOnly、Secure 一起核查,避免属性互相打架

下发示例

下发示例
# 通用站点:默认用 Lax
Set-Cookie: session=abc; Path=/; Secure; HttpOnly; SameSite=Lax

# 高敏感后台:收紧到 Strict
Set-Cookie: admin_session=xyz; Path=/admin; Secure; HttpOnly; SameSite=Strict

# 需要跨站携带(谨慎评估后使用)
Set-Cookie: sso_state=def; Path=/; Secure; SameSite=None

# 核查线上实际下发:
# curl -sI https://example.com/login | grep -i set-cookie
把后台从 Lax 改为 Strict 能进一步收窄跨站面,但必须回归『从邮件、工单、IM 外链进入』的流程,否则会出现登录态丢失的投诉。
SameSite=None 缺少 Secure 属性时浏览器会直接丢弃该 Cookie,表现为登录随机失效,排查时优先核对这两个属性是否成对出现。

易错点

  • SameSite=None 未配 Secure:Cookie 被浏览器拒绝,用户表现为反复掉登录
  • 只依赖 SameSite 不做令牌校验:旧浏览器与同站子域场景下仍有残余 CSRF 风险
  • 改用 Strict 后未回归外链入口流程:从邮件或第三方系统跳转时登录态丢失
  • 多个接口下发同名 Cookie 且属性不一致:浏览器以最后一次设置为准,原加固属性被静默覆盖

数据来源与参考

  • MDN SameSite Cookie 文档
  • RFC 6265bis(SameSite 语义)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌