浏览器安全体系：同源策略、攻击防御与加密传输

0. 引言

浏览器安全涵盖三个维度：Web 页面安全（同源策略、XSS/CSRF 防御）、浏览器系统安全（安全沙箱、站点隔离）和网络安全（HTTPS/TLS）。本文将系统性地阐述这三个层面的安全机制，涵盖 COOP/COEP、Trusted Types、SameSite Cookie 默认值变更、Privacy Sandbox、Passkeys 等 2019 年以来的重大安全演进。

1. 同源策略（Same-Origin Policy）

1.1 同源定义

两个 URL 同源当且仅当协议（scheme）、主机（host）和端口（port）完全相同：

1.2 同源策略的三层限制

1.3 跨源资源共享（CORS）

CORS 通过 HTTP 头部协商允许跨源访问：

1.4 跨源隔离（Cross-Origin Isolation）

2020 年 Chrome 引入 COOP/COEP 机制，实现跨源隔离，作为使用 SharedArrayBuffer 等高权限 API 的前提：

设置 COOP: same-origin + COEP: require-corp 后，页面进入跨源隔离状态，可使用：

• SharedArrayBuffer（多线程共享内存）
• 高精度计时器（performance.now() 微秒级精度）
• measureUserAgentSpecificMemory() API

2. XSS 攻击与防御

2.1 攻击类型

2.2 现代防御体系

2.2.1 内容安全策略（CSP）

CSP 通过 HTTP 头声明允许加载的资源来源：

Content-Security-Policy:
    default-src 'self';
    script-src 'self' 'nonce-abc123';
    style-src 'self' 'unsafe-inline';
    img-src 'self' data: https:;
    connect-src 'self' https://api.example.com;
    report-uri /csp-violation-report;

CSP 3 及 Trusted Types 相关指令：

2.2.2 Trusted Types API

2020 年起在 Chrome 中落地的 Trusted Types 在 DOM 层面阻止 XSS 注入——禁止将字符串直接赋值给危险的 DOM Sink：

// ❌ 默认禁止（抛出 TypeError）
element.innerHTML = userInput;
document.write(untrustedData);

// ✅ 通过 Trusted Types 策略创建安全值
const policy = trustedTypes.createPolicy('sanitizer', {
    createHTML: (input) => DOMPurify.sanitize(input)
});
element.innerHTML = policy.createHTML(userInput);

2.2.3 Sanitizer API

Sanitizer API 提供浏览器原生的 HTML 净化能力（截至 2026-09 标准化仍在推进中，各浏览器支持程度不一）：

const sanitizer = new Sanitizer({
    allowElements: ['b', 'i', 'em', 'strong', 'a'],
    allowAttributes: { 'a': ['href'] }
});
element.setHTML(userInput, { sanitizer });

3. CSRF 攻击与防御

3.1 攻击原理

CSRF（Cross-Site Request Forgery）利用用户已认证的身份，在用户不知情的情况下发起跨站请求：

3.2 SameSite Cookie 演进

Set-Cookie: session=abc; SameSite=Strict; Secure; HttpOnly

3.3 其他 CSRF 防御

• CSRF Token：表单中嵌入服务器生成的随机令牌，提交时验证
• 双重 Cookie 验证：Cookie 中的值与请求参数中的值匹配
• 自定义请求头：AJAX 请求添加 X-Requested-With 头，跨站伪造的请求无法自行添加该头

4. 安全沙箱与站点隔离

4.1 安全沙箱机制

Chrome 利用操作系统级沙箱限制渲染进程的系统调用：

4.2 Site Isolation（站点隔离）

2018 年 Spectre 漏洞促使 Chrome 全面实施站点隔离：

• 标签页级隔离 → 站点级隔离：不同站点的 iframe 运行于不同渲染进程
• 进程级内存隔离：利用操作系统进程隔离机制阻止跨站点内存读取
• COOP/COEP 强制执行：站点隔离为跨源隔离提供进程级保障

5. HTTPS 与 TLS 1.3

5.1 HTTPS 的安全层

HTTPS 在 HTTP 与 TCP 之间插入 TLS 安全层，实现：

• 加密：防止窃听
• 完整性：防止篡改
• 认证：防止冒充

5.2 TLS 1.3 握手

TLS 1.3 强制前向保密（ECDHE 密钥交换），移除弱密码算法，将握手从 2-RTT 缩短至 1-RTT：

5.3 证书透明度（Certificate Transparency）

CT 要求 CA 将签发的证书提交到公开日志，任何人可审计：

• 防止 CA 签发未授权证书
• 域名所有者可监控为其域名签发的证书
• Chrome 要求所有 TLS 证书必须提供 SCT 证明（常见做法是将 SCT 内嵌在证书中）

5.4 HTTPS-First Mode

2023—2024 年 Chrome 推出 HTTPS-First Mode：

• 用户输入不含协议的 URL 时，默认使用 HTTPS
• HTTP 连接失败时显示警告页面
• 目标：最终将 HTTP 降级为需要显式选择的协议

6. Privacy Sandbox 与第三方 Cookie 治理

6.1 第三方 Cookie 治理时间线

截至 2026-09，Chrome 未再推进第三方 Cookie 的全面淘汰，Privacy Sandbox 转向以提供可选替代 API 为主的路线。

6.2 替代方案

6.3 Storage Partitioning

所有浏览器存储（Cookie、localStorage、IndexedDB、Cache API）按顶级站点 + 源分区：

传统：evil.com 的 iframe 在 bank.com 中访问 evil.com 的 Cookie
分区后：evil.com 的 iframe 在 bank.com 中访问 [bank.com, evil.com] 分区的 Cookie
         → 与直接访问 evil.com 时的 Cookie 不同

7. Passkeys 与 WebAuthn

7.1 密码的终结

2022—2024 年，Apple、Google、Microsoft 联合推动 Passkeys（基于 FIDO2/WebAuthn 标准），用公钥密码替代传统密码：

Passkeys 的安全优势：

• 无密码可被钓鱼/泄露
• 认证过程绑定源（Origin），防止钓鱼攻击
• 私钥永不离开设备安全芯片
• 支持跨设备同步（iCloud Keychain / Google Password Manager）

8. 总结

浏览器安全的演进方向清晰：从被动防御走向主动防护——COOP/COEP 主动隔离跨源上下文，Trusted Types 在 DOM 写入时阻止 DOM XSS，SameSite 默认值消除了大量 CSRF 攻击面，Passkeys 从根本上消除了密码泄露风险。理解这一安全体系的完整图景，是构建安全 Web 应用的必要前提。

下一章讲解 HTTPS：浏览器如何验证数字证书。

参考文献

1. W3C: CORS
2. W3C: Trusted Types
3. W3C: Sanitizer API
4. RFC 8446: TLS 1.3
5. W3C: WebAuthn Level 3
6. Chrome Blog: Privacy Sandbox
7. FIDO Alliance: Passkeys