引言：从一个简单的HTTP请求说起
当我们在浏览器中打开一个网页，在控制台中执行一行看似简单的代码时：
fetch('http://localhost:8000/api/test')
.then(res => res.json())
.then(data => console.log(data));
如果当前页面运行在 http://localhost:5173，浏览器会毫不留情地抛出一个错误：
Access to fetch at 'http://localhost:8000/api/test' from origin 'http://localhost:5173'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.
这个看似简单的错误背后，隐藏着浏览器安全架构中最核心的机制之一——同源策略（Same-Origin Policy）。要真正理解跨域问题，我们需要深入浏览器的内核，探索这个策略是如何在底层实现的，以及它为什么如此重要。
第一章：浏览器安全模型的底层架构
1.1 多进程架构与安全边界
现代浏览器采用多进程架构，这不仅是为了性能和稳定性，更是为了构建强大的安全边界。以 Chromium 为例，其主要进程包括：
Browser Process（浏览器主进程）：负责用户界面、网络请求、文件访问等特权操作。这个进程拥有完整的系统权限，是整个浏览器的"大脑"。
Renderer Process（渲染进程）：每个标签页通常对应一个独立的渲染进程，负责HTML解析、CSS渲染、JavaScript执行等。这些进程运行在沙箱环境中，权限受到严格限制。
Network Service Process（网络服务进程）：专门处理网络请求，包括DNS解析、TCP连接建立、HTTP协议处理等。
GPU Process（GPU进程）：处理图形渲染相关的任务。
这种架构的关键在于，同源策略主要在渲染进程中实施，但网络请求的最终决策权在浏览器主进程。当渲染进程中的JavaScript代码尝试发起一个跨域请求时，实际的网络通信是由网络服务进程处理的，而同源策略的检查则分布在多个层面。
1.2 同源策略的多层实现机制
同源策略并不是一个单一的检查点，而是一个分布在浏览器各个层面的安全机制：
JavaScript引擎层面：V8引擎在执行fetch()、XMLHttpRequest等API时，会首先检查目标URL与当前页面的源是否相同。如果不同，会标记这是一个跨域请求。
网络栈层面：在实际发送HTTP请求之前，浏览器的网络栈会在请求头中自动添加Origin字段，标明请求的来源。
响应处理层面：当收到服务器响应时，浏览器会检查响应头中的CORS相关字段，决定是否将响应数据暴露给JavaScript代码。
让我们通过一个具体的例子来理解这个过程：
// 在 http://localhost:5173 页面中执行
fetch('http://localhost:8000/api/test', {
method: 'PATCH',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({data: 'test'})
});
这个请求的处理流程如下：
- JavaScript引擎检查：V8引擎识别出这是一个跨域请求（端口不同）
- 预检请求判断：由于使用了PATCH方法和application/json内容类型，这是一个"复杂请求"，需要预检
- 预检请求发送：浏览器自动发送OPTIONS请求到目标服务器
- 预检响应检查：检查服务器返回的CORS头信息
- 实际请求发送：如果预检通过，发送真正的PATCH请求
- 响应处理：再次检查响应的CORS头，决定是否将数据暴露给JavaScript
第二章：同源策略的精确定义与边界情况
2.1 源（Origin）的精确计算
在浏览器内核中，源的计算并不是简单的字符串比较，而是一个复杂的解析和标准化过程。以Chromium的实现为例，源的计算涉及以下步骤：
URL解析与标准化：浏览器首先使用WHATWG URL标准解析URL，这个过程包括：
- 协议标准化（如将
HTTP转换为http） - 主机名标准化（如将
LOCALHOST转换为localhost） - 端口标准化（如为http协议补充默认端口80）
- 路径和查询参数的忽略（源的计算不包含这些部分）
特殊协议的处理：不同协议有不同的源计算规则：
http和https：标准的协议+主机+端口组合file：每个文件都被视为不同的源（在某些浏览器中）data和blob：继承创建它们的文档的源chrome-extension：每个扩展有唯一的源标识
让我们看一个具体的源计算示例：
// 浏览器内核中的源计算逻辑（简化版）
function calculateOrigin(url) {
const parsed = new URL(url);
// 协议标准化
const scheme = parsed.protocol.toLowerCase();
// 主机标准化
const host = parsed.hostname.toLowerCase();
// 端口处理
let port = parsed.port;
if (!port) {
// 补充默认端口
if (scheme === 'http:') port = '80';
else if (scheme === 'https:') port = '443';
else if (scheme === 'ftp:') port = '21';
}
// 特殊协议处理
if (scheme === 'file:') {
return 'null'; // file协议通常返回null源
}
return `${scheme}//${host}:${port}`;
}
// 测试用例
console.log(calculateOrigin('HTTP://LOCALHOST:3000/api/test?id=1'));
// 输出: "http://localhost:3000"
console.log(calculateOrigin('https://example.com/'));
// 输出: "https://example.com:443"
2.2 同源检查的底层实现
在Chromium源码中，同源检查主要在url::Origin类中实现。这个类不仅负责源的计算，还提供了高效的比较方法：
// Chromium源码中的同源检查（简化版）
bool Origin::IsSameOriginWith(const Origin& other) const {
return scheme_ == other.scheme_ &&
host_ == other.host_ &&
port_ == other.port_ &&
domain_was_unicode_ == other.domain_was_unicode_;
}
这个检查过程看似简单，但在实际实现中需要考虑许多边界情况：
Unicode域名处理：对于包含Unicode字符的域名，浏览器需要进行Punycode转换，确保比较的一致性。
IP地址标准化：IPv4和IPv6地址需要标准化处理，例如127.0.0.1和localhost在某些情况下被视为相同。
端口省略规则：当端口是协议的默认端口时，比较时需要考虑省略情况。
2.3 同源策略的例外情况
同源策略并不是绝对的，浏览器内核中实现了多种例外情况：
document.domain降域：JavaScript可以通过设置document.domain来放宽同源限制，但这只适用于同一父域的子域之间：
// 在 sub1.example.com 页面中
document.domain = 'example.com';
// 在 sub2.example.com 页面中
document.domain = 'example.com';
// 现在这两个页面可以相互访问
在浏览器内核中，这个机制通过维护一个"有效域"（effective domain）来实现，当JavaScript设置document.domain时，浏览器会更新这个有效域，并在后续的同源检查中使用它。
postMessage跨域通信：window.postMessageAPI允许不同源的窗口之间进行安全通信：
// 父窗口（http://localhost:5173）
const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Hello', 'http://localhost:8000');
// 子窗口（http://localhost:8000）
window.addEventListener('message', (event) => {
if (event.origin !== 'http://localhost:5173') return;
console.log('收到消息:', event.data);
});
这个机制在浏览器内核中通过消息队列和源验证来实现，确保消息只能被指定源的窗口接收。
第三章：网络请求的底层处理机制
3.1 HTTP请求的生命周期
当JavaScript代码发起一个网络请求时，这个请求会经历复杂的处理流程。让我们以一个具体的跨域请求为例：
fetch('http://localhost:8000/api/test', {
method: 'PATCH',
headers: {
'Content-Type': 'application/json',
'X-Custom-Header': 'value'
},
body: JSON.stringify({data: 'test'})
});
第一阶段：请求预处理
在渲染进程中，JavaScript引擎首先会进行以下检查：
- URL有效性验证：确保URL格式正确，协议被支持
- 同源策略初步检查：判断是否为跨域请求
- 请求类型分类：判断是简单请求还是复杂请求
对于上述请求，由于使用了PATCH方法和自定义头，被归类为复杂请求，需要预检。
第二阶段：预检请求生成
浏览器会自动生成一个OPTIONS预检请求：
OPTIONS /api/test HTTP/1.1
Host: localhost:8000
Origin: http://localhost:5173
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: content-type,x-custom-header
这个预检请求的生成完全由浏览器内核控制，JavaScript代码无法干预。
第三阶段：网络传输
预检请求通过浏览器的网络栈发送到目标服务器。在这个过程中，浏览器会：
- DNS解析：将域名解析为IP地址
- 连接建立：建立TCP连接（如果是HTTPS还需要TLS握手）
- 请求发送：发送HTTP请求数据
- 响应接收：接收服务器响应
第四阶段：预检响应处理
当收到预检响应时，浏览器会检查以下头信息：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Custom-Header
Access-Control-Max-Age: 86400
浏览器内核会验证：
Access-Control-Allow-Origin是否包含当前源Access-Control-Allow-Methods是否包含PATCHAccess-Control-Allow-Headers是否包含所有自定义头
只有所有检查都通过，才会发送实际的业务请求。
3.2 CORS缓存机制
为了提高性能，浏览器实现了CORS预检缓存机制。当服务器在预检响应中包含Access-Control-Max-Age头时，浏览器会缓存这个预检结果：
// 浏览器内核中的CORS缓存（概念性实现）
class CORSCache {
constructor() {
this.cache = new Map();
}
// 生成缓存键
generateKey(origin, url, method, headers) {
return `${origin}:${url}:${method}:${headers.sort().join(',')}`;
}
// 检查缓存
checkCache(origin, url, method, headers) {
const key = this.generateKey(origin, url, method, headers);
const cached = this.cache.get(key);
if (cached && Date.now() < cached.expiry) {
return cached.allowed;
}
return null; // 缓存未命中或已过期
}
// 更新缓存
updateCache(origin, url, method, headers, allowed, maxAge) {
const key = this.generateKey(origin, url, method, headers);
this.cache.set(key, {
allowed: allowed,
expiry: Date.now() + maxAge * 1000
});
}
}
这个缓存机制大大减少了不必要的预检请求，提高了跨域请求的性能。
第四章：安全威胁与防护机制
4.1 跨站请求伪造（CSRF）的深层原理
同源策略的一个重要目标是防止跨站请求伪造攻击。让我们深入理解这种攻击的原理：
攻击场景：用户在银行网站（bank.com）登录后，访问了恶意网站（evil.com）。恶意网站试图利用用户的登录状态，向银行网站发送转账请求。
没有同源策略的世界：
<!-- 恶意网站 evil.com 上的代码 -->
<script>
// 如果没有同源策略，这段代码可以成功执行
fetch('https://bank.com/api/transfer', {
method: 'POST',
credentials: 'include', // 包含cookies
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
to: 'attacker-account',
amount: 10000
})
}).then(response => {
// 攻击者可以读取响应，获取用户账户信息
return response.json();
}).then(data => {
console.log('用户账户信息:', data);
});
</script>
同源策略的保护：
- 请求发送限制：浏览器会阻止跨域的复杂请求（如包含自定义头的POST请求）
- 响应读取限制：即使请求被发送，浏览器也不会将响应数据暴露给恶意脚本
- Cookie隔离：不同源的页面无法访问彼此的Cookie
4.2 同源策略的实现细节
在浏览器内核中，同源策略的实施涉及多个组件的协作：
渲染引擎层面：
- DOM访问控制：不同源的iframe无法访问彼此的DOM
- 存储隔离：localStorage、sessionStorage按源隔离
- Cookie访问控制：JavaScript只能访问同源的Cookie
网络层面：
- 请求头自动添加：自动添加Origin头标识请求来源
- 响应过滤：根据CORS头决定是否暴露响应数据
- 预检机制：对复杂请求进行预检验证
JavaScript引擎层面：
- API访问控制：限制跨域的XMLHttpRequest和fetch调用
- 错误信息过滤：跨域脚本错误信息被过滤，防止信息泄露
让我们看一个具体的实现示例：
// 浏览器内核中的跨域检查（概念性实现）
class SecurityManager {
// 检查DOM访问权限
checkDOMAccess(sourceOrigin, targetOrigin) {
if (sourceOrigin === targetOrigin) {
return true;
}
// 检查document.domain设置
if (this.checkDocumentDomain(sourceOrigin, targetOrigin)) {
return true;
}
return false;
}
// 检查网络请求权限
checkNetworkAccess(sourceOrigin, targetURL, method, headers) {
const targetOrigin = this.calculateOrigin(targetURL);
if (sourceOrigin === targetOrigin) {
return { allowed: true, needsPreflight: false };
}
// 跨域请求，检查是否需要预检
const needsPreflight = this.isPreflightRequired(method, headers);
return { allowed: false, needsPreflight: needsPreflight };
}
// 判断是否需要预检
isPreflightRequired(method, headers) {
// 简单方法
const simpleMethods = ['GET', 'HEAD', 'POST'];
if (!simpleMethods.includes(method)) {
return true;
}
// 检查头信息
for (const [name, value] of Object.entries(headers)) {
if (!this.isSimpleHeader(name, value)) {
return true;
}
}
return false;
}
// 判断是否为简单头
isSimpleHeader(name, value) {
const simpleHeaders = [
'accept',
'accept-language',
'content-language',
'content-type'
];
const lowerName = name.toLowerCase();
if (!simpleHeaders.includes(lowerName)) {
return false;
}
// Content-Type的特殊检查
if (lowerName === 'content-type') {
const simpleContentTypes = [
'application/x-www-form-urlencoded',
'multipart/form-data',
'text/plain'
];
return simpleContentTypes.includes(value.toLowerCase());
}
return true;
}
}
4.3 现代浏览器的安全增强
现代浏览器在同源策略的基础上，还实现了许多额外的安全机制：
Site Isolation（站点隔离）：Chromium实现的站点隔离机制确保不同站点的内容运行在不同的进程中，即使存在漏洞也难以跨站点攻击。
Trusted Types：防止DOM XSS攻击的新机制，要求危险的DOM操作使用可信类型。
Cross-Origin Embedder Policy (COEP)：控制页面是否可以嵌入跨域资源。
Cross-Origin Opener Policy (COOP)：控制页面是否可以被其他页面通过window.open打开。
这些机制共同构成了现代Web的安全防护体系，而同源策略是这个体系的基石。
结语
同源策略不仅仅是一个简单的安全规则，它是现代浏览器安全架构的核心。从JavaScript引擎到网络栈，从DOM访问控制到存储隔离，同源策略的实现涉及浏览器的各个层面。
理解这些底层机制，不仅有助于我们更好地处理跨域问题，更重要的是让我们认识到Web安全的复杂性和重要性。在下一篇博客中，我们将深入探讨各种跨域解决方案的底层实现，包括JSONP的巧妙设计、CORS的完整机制，以及现代Web开发中的高级跨域技术。
