老旧浏览器中 SameSite=Strict 的已知实现漏洞与缺陷

更新: 5/24/2026 字数: 0 字 时长: 0 分钟

这是个非常专业的问题。下面整理业界已公开记录的浏览器对 SameSite 属性的实现缺陷,涵盖完全不支持、部分支持有 bug、以及已记录 CVE 的版本。建议结合自己业务的用户群浏览器分布参考评估。

一、完全不支持 SameSite 的浏览器(直接当无防御)

这些浏览器完全忽略 SameSite 属性,Cookie 会按默认行为发送——CSRF 防御完全失效。

浏览器	不支持版本	备注
Internet Explorer	IE 11 及以下全部版本	Windows 7/8 上的 IE 11 完全不识别 SameSite
Edge Legacy(非 Chromium)	< Edge 16	老版 EdgeHTML 内核
Chrome	< Chrome 51	2016 年 5 月之前的版本
Firefox	< Firefox 60	2018 年 5 月之前的版本
Safari (macOS)	< Safari 12	macOS High Sierra 及更早系统自带
Safari (iOS)	< iOS 12	影响 iPhone 5s/6 等老设备
Opera	< Opera 39	2016 年之前的版本
Android Browser	< 4.4	KitKat 之前的系统自带浏览器
Samsung Internet	< 5.0	老版三星浏览器
UC Browser	多数老版本	国内场景常见,合规性差
Opera Mini	全部版本(包括最新)	因其代理压缩架构,Cookie 行为异常

数据来源:可参考 Can I use - SameSite 查询最新兼容性数据。

二、"支持但有重大 bug"的版本(更危险,以为有防御实则没有)

这类比完全不支持更隐蔽——开发者以为防御生效,实际存在绕过路径。

1. iOS 12 / macOS 10.14 Safari(已记录的最严重缺陷)

• 问题:Safari 12 将 SameSite=None 错误地当作 SameSite=Strict 处理。
• 后果:开发者为了支持跨站(如嵌入式 OAuth)显式设置 SameSite=None,在 iOS 12 上反而变成最严格模式,业务直接挂掉;或反过来,迁移配置时埋下隐患。
• 影响:iOS 12.x 全系列(2018 年 9 月 - 2019 年 9 月发布)、macOS Mojave 10.14 Safari。
• 官方致歉:WebKit 团队在 2019 年底通过 博客 Bug 19761 承认并修复,详见 Chromium 文档说明。

2. Chrome 51 - 66

• 问题:早期实现中,在某些 iframe 嵌套场景下 SameSite 判定不一致。
• 影响:可能在特定子框架情况下错误地携带或不携带 Cookie。
• 修复版本:Chrome 67+ 大幅改进。

3. Chrome 76 之前(Lax + POST 缓冲期)

• 问题:Chrome 在 76-79 版本期间引入"Lax + POST"过渡机制,跨站 POST 请求在 2 分钟内仍会携带 SameSite=Lax 的 Cookie。
• 后果:Lax 模式下存在 2 分钟的 CSRF 攻击窗口。
• 背景:这是为了平滑迁移而设的临时机制,在 Chrome 80+ 默认值变更后逐步收紧。

4. Firefox 60 - 68

• 问题:对 SameSite 属性大小写敏感性处理不严格,某些边缘场景下 samesite=Strict(小写)可能不生效。
• 修复版本:Firefox 69+。

5. Safari 13 早期版本

• 问题:在子框架(subframe)的导航请求中,SameSite 判定与其他浏览器不一致。
• 影响:Safari 13.0 - 13.0.5。
• 修复版本:Safari 13.1。

6. 各 WebView 嵌入式浏览器

• 微信内置 WebView(基于较老 Chromium 内核):部分版本 SameSite 行为不一致。
• Android System WebView < 76:不支持新 SameSite 默认值变更。
• Cordova / Capacitor 等混合应用框架:依赖底层 WebView 版本,行为不可控。
• 企业 App 内嵌浏览器:常基于老版 Chromium,需逐一测试。

三、有 CVE 记录的相关安全问题

虽然直接针对 SameSite 实现的 CVE 不多,但以下与 Cookie/CSRF 防御链相关的 CVE 值得关注:

CVE 编号	影响	说明
CVE-2020-16012	Firefox < 82	与 Cookie 时序/缓存相关的侧信道问题,可能影响 SameSite 防御链
CVE-2019-11759	Firefox < 70	Cookie 处理相关漏洞
CVE-2018-6149	Chrome < 67	Cookie 处理逻辑缺陷
CVE-2020-6442	Chrome < 80	Cache 中的 Cookie 处理问题

注:这些 CVE 通常不是"SameSite 直接被绕过",而是攻击者通过其他路径削弱了包括 SameSite 在内的 Cookie 安全机制。完整列表可在 NVD 或 MITRE CVE 数据库 检索 "samesite cookie"。

四、行为差异显著的"实现不一致"问题

即使是支持 SameSite 的浏览器,各家对边缘情况的处理也不完全一致:

1. "Same Site" 的定义差异

• 公共后缀列表(PSL)依赖:浏览器判断 "same site" 依赖 Public Suffix List。
• 各浏览器更新 PSL 的频率不同,新注册的特殊后缀(如 .dev、.app)在不同浏览器中识别时间不一致。
• 后果:同一对域名,在 Chrome 中是"同站",在 Firefox 中可能是"跨站"。

2. 重定向链中的 Cookie 处理

• 浏览器对跨站重定向链中 SameSite Cookie 的处理逻辑不同:
  • Chrome:只看最终请求是否跨站
  • Firefox:某些版本会看整个链路
  • Safari:策略更严格,链中任一跨站则不带

3. 预加载/预渲染请求

• <link rel="prefetch">、<link rel="preload"> 等预加载请求的 SameSite 处理没有统一标准。
• 各浏览器实现差异较大,某些版本可能错误地携带或丢弃 Cookie。

4. Service Worker 拦截请求

• Service Worker 拦截并重发的请求,SameSite 判定基于"原始请求"还是"重发请求",各浏览器不一致。

5. 跨站 iframe 中的弹窗

• iframe 内通过 window.open 打开同站页面,SameSite 判定逻辑在 Safari 与 Chrome 之间存在差异。

五、国内场景需特别关注的浏览器

国内市场情况更复杂,以下浏览器尤其需要测试:

浏览器	主要风险
QQ 浏览器(老版)	基于较老 Chromium 内核,SameSite 行为可能滞后
360 浏览器	双内核切换,SameSite 行为依赖当前模式
搜狗浏览器	老版本对 SameSite 支持不完整
UC 浏览器	代理云加速架构可能影响 Cookie 行为
微信内置 WebView	内核版本碎片化,iOS/Android 行为不同
支付宝小程序 WebView	行为受小程序框架影响
企业级浏览器(IE 模式)	一些政企/银行系统仍强制使用 IE 模式

六、实战建议:如何评估 SameSite 在你业务中的可靠性

1. 检查用户群浏览器分布

通过埋点统计真实用户的浏览器版本:

// 简化的浏览器检测
const ua = navigator.userAgent;
const isLegacy = /MSIE|Trident|Edge\/1[0-7]/.test(ua) || 
                 /Chrome\/[1-4]\d\./.test(ua);
if (isLegacy) {
  // 上报给监控系统
}

如果老旧浏览器占比 > 1%,SameSite 单独防御就不够。

2. 通过工具实测各浏览器行为

• SameSite 测试页面
• Cookie Inspector
• BrowserStack / Sauce Labs 上覆盖目标浏览器矩阵进行回归

3. 持续关注以下信息源

• Chromium SameSite 兼容性文档
• Mozilla Bug Tracker 搜索 "samesite"
• WebKit Bug Tracker 搜索 "samesite"
• Can I use - SameSite
• OWASP CSRF Prevention Cheat Sheet

七、风险等级总结

浏览器场景	风险等级	建议
现代 Chrome/Firefox/Edge/Safari 最新 3 版	🟢 低	SameSite=Strict 防御可靠
现代浏览器但旧版(2-3 年前)	🟡 中	已知 bug 多,需测试关键场景
IE 11 / 老版 Edge	🔴 高	完全无防御,必须配合 CSRF Token
iOS 12 / Safari 12	🔴 高	有已知错误处理 bug
嵌入式 WebView(微信/支付宝/企业 App)	🟠 偏高	行为不可控,务必双重防御
国内第三方浏览器	🟠 偏高	内核版本碎片化,建议保守对待

八、一句话总结

SameSite=Strict 在"现代主流浏览器最新几个版本"中是可靠的,但只要你的用户群涉及 IE 11、iOS 12 Safari、嵌入式 WebView 或国内非主流浏览器,就一定存在防御失效的窗口。 已记录的真实问题包括 iOS 12 Safari 把 SameSite=None 当 Strict 的处理错误、Chrome 早期的 Lax+POST 过渡窗口、各浏览器对"同站"判定和重定向链的实现差异等。正因如此,业界共识是把 SameSite 当作"浏览器层的纵深防御"而非"唯一防线",必须始终配合应用层的 CSRF Token + Origin 校验,才能在某一层失效时仍有兜底。