浏览器同源策略（SOP）的例外：CORS、PostMessage 与 document.domain 的安全边界

大家好，今天我们来深入探讨一个非常关键但常被误解的话题——浏览器同源策略（Same-Origin Policy, SOP）的例外机制。
你可能已经听过“跨域”、“CORS”、“postMessage”这些词，但你知道它们背后的原理吗？更重要的是，它们之间有什么区别？各自的使用边界在哪里？如何避免安全漏洞？

这篇文章将以讲座的形式展开，逻辑清晰、代码详实，适合前端开发者、后端工程师和安全研究人员阅读。我们将从基础讲起，逐步深入，并通过实际代码演示每种机制的工作方式，最后总结出一套清晰的安全边界判断标准。

一、什么是同源策略（SOP）？

首先明确一点：同源策略是浏览器最核心的安全机制之一。

同源定义

两个 URL 被认为是“同源”的，当且仅当：

协议相同（如都是 http 或 https）
域名相同（如 example.com 和 example.com）
端口相同（如 8080 和 8080）

举个例子：

URL	是否同源
`https://api.example.com:8080/data`	——
`https://api.example.com:8080/data`	✅ 是
`https://api.example.com:3000/data`	❌ 否（端口不同）
`http://api.example.com:8080/data`	❌ 否（协议不同）
`https://admin.example.com:8080/data`	❌ 否（域名不同）

🧠 注意：即使两个站点在同一个物理服务器上，只要域名或端口不同，就属于不同源。

SOP 的作用是什么？

它阻止了恶意脚本从一个源（比如 evil.com）访问另一个源（比如 bank.com）的数据，从而防止 CSRF、XSS 等攻击。

但现实世界中，我们确实需要跨域通信——比如前端调用后端 API、iframe 内嵌第三方页面等。于是，浏览器设计了几种合法的“例外”，下面我们就一一介绍。

二、CORS：跨域资源共享（Cross-Origin Resource Sharing）

这是目前最主流的跨域解决方案，主要用于 AJAX 请求（XMLHttpRequest / Fetch API）。

CORS 工作原理简述

浏览器发起请求时，如果目标 URL 不同源，则会自动添加一个 Origin 头。
服务端收到请求后，决定是否允许该来源（通过响应头 Access-Control-Allow-Origin）。
如果允许，浏览器才允许 JavaScript 访问响应内容。

示例代码：客户端请求 + 服务端响应

客户端（前端）

fetch('https://api.example.com/users', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(err => console.error('Error:', err));

服务端（Node.js + Express）

const express = require('express');
const app = express();

// 允许特定来源访问
app.use((req, res, next) => {
  const allowedOrigins = ['https://myapp.com'];
  const origin = req.headers.origin;

  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }

  // 可选：支持预检请求（Preflight）
  if (req.method === 'OPTIONS') {
    res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    return res.status(200).send();
  }

  next();
});

app.get('/users', (req, res) => {
  res.json([{ id: 1, name: 'Alice' }]);
});

app.listen(3000);

✅ 这样配置后，浏览器就知道这个接口可以被 https://myapp.com 访问！

CORS 的限制与风险点

特性	描述	安全提示
`Access-Control-Allow-Origin: *`	允许所有来源	⚠️ 不要用于敏感接口！易受CSRF攻击
预检请求（Preflight）	对复杂请求（如PUT、带自定义头）触发 OPTIONS 请求	必须正确处理，否则失败
Credentials（cookie、auth）	默认不发送凭据，需显式设置 `withCredentials: true`	若启用，必须指定具体 Origin，不能用 `*`

💡 实际项目建议：

使用 Access-Control-Allow-Origin 显式指定允许的域名列表；
敏感接口不要暴露给任意来源；
开启 withCredentials 时务必确保 Origin 白名单可控。

三、PostMessage：跨窗口/跨frame通信

适用于 不同源之间的窗口通信，比如：

iframe 与父页面通信；
弹窗（popup）与主窗口通信；
Worker 与主线程通信（部分场景）；

工作原理

发送方调用 window.postMessage(data, targetOrigin)；
接收方监听 message 事件；
浏览器强制检查 targetOrigin 是否匹配，若不匹配则忽略消息。

示例代码：父子窗口通信

父页面（index.html）

<iframe id="child" src="https://child.example.com"></iframe>
<script>
  const childFrame = document.getElementById('child').contentWindow;

  // 发送消息给子窗口
  childFrame.postMessage({ type: 'hello', payload: 'from parent' }, 'https://child.example.com');

  // 监听来自子窗口的消息
  window.addEventListener('message', function(event) {
    if (event.origin !== 'https://child.example.com') {
      console.warn('Invalid origin:', event.origin);
      return;
    }
    console.log('Received from child:', event.data);
  });
</script>

子页面（child.example.com/index.html）

<script>
  // 监听来自父窗口的消息
  window.addEventListener('message', function(event) {
    if (event.origin !== 'https://yourdomain.com') {
      console.warn('Invalid origin:', event.origin);
      return;
    }

    console.log('Received from parent:', event.data);

    // 回复父窗口
    event.source.postMessage({
      type: 'response',
      message: 'Hello from child!'
    }, event.origin); // 必须用 event.origin，而非固定值
  });
</script>

PostMessage 的安全边界

安全要点	解释
`event.origin` 校验	必须严格校验来源，否则可能被伪造
`event.source` 使用	应该用来回复对方，而不是随意信任
不要直接使用 `*` 作为 targetOrigin	如 `postMessage(..., '*')`，可能导致任意站点接收你的消息

📌 重要提醒：PostMessage 不提供数据加密或身份认证功能，完全依赖于双方对 origin 的验证逻辑。一旦校验失败，就会变成“可被劫持的通道”。

四、document.domain：同一主域名下的子域共享

这是一个比较老但仍有用的技术，用于解决 同一主域下不同子域间的 DOM 访问问题。

场景举例

假设你有：

a.example.com
b.example.com

它们都属于 example.com，但默认情况下无法互相访问 DOM（例如读取 cookie、操作 DOM）。

使用方法

页面 A（a.example.com）

<script>
  document.domain = 'example.com'; // 设置为公共父域
</script>

页面 B（b.example.com）

<script>
  document.domain = 'example.com';
</script>

此时，两者就可以互相访问彼此的 DOM（如 localStorage、cookie），前提是：

两个页面都设置了相同的 document.domain；
并且运行在同一浏览器标签页内（即不是跨 tab）；

示例：跨子域读取 localStorage

// a.example.com 设置
document.domain = 'example.com';
localStorage.setItem('token', 'abc123');

// b.example.com 也能读到
document.domain = 'example.com';
console.log(localStorage.getItem('token')); // 输出 "abc123"

安全边界说明

条件	是否允许
两个页面均设置 `document.domain` 为相同值	✅
两个页面不在同一个浏览器标签页	❌ 不行（跨 tab 不生效）
设置成非父域（如 `a.example.com` 设置为 `b.example.com`）	❌ 报错
没有设置 `document.domain`	❌ 不允许访问其他子域的 DOM

⚠️ 警告：document.domain 是一种“降级”行为，它削弱了原本的同源策略。如果你的应用中有多个子域，应优先考虑使用 CORS 或 postMessage 来替代这种做法。

五、三种机制对比表（重点总结）

特性	CORS	PostMessage	document.domain
主要用途	AJAX 请求跨域	窗口/iframe 间通信	同一主域下子域间通信
是否需要服务端配合	✅ 是	❌ 否（纯前端）	✅ 是（双方都要改）
支持 Cookie	✅ 可配置	❌ 不支持	✅ 可以（依赖 cookie）
是否需要 Origin 校验	✅ 是	✅ 是	❌ 不校验（只看 domain）
安全级别	中高	中	低（容易误用）
典型应用场景	API 调用、图片加载	iframe 通信、弹窗交互	内部系统微服务通信（如 admin.example.com vs api.example.com）

📌 推荐选择顺序：

优先使用 CORS（API 接口）；
其次使用 PostMessage（窗口通信）；
谨慎使用 document.domain（仅限内部子域）；

六、常见误区与防御建议

❌ 误区一：“用了 CORS 就万无一失”

很多开发者以为只要加了 Access-Control-Allow-Origin 就安全了，其实不然：

若设为 *，任何网站都能获取你的数据；
若未校验 Origin，可能被钓鱼网站利用。

✅ 正确做法：

if (allowedOrigins.includes(req.headers.origin)) {
  res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
}

❌ 误区二：“postMessage 不用校验 origin”

有人写：

window.addEventListener('message', e => {
  console.log(e.data); // 危险！
});

这会导致任意来源都可以向你的页面发消息，甚至注入恶意脚本！