深入解析跨域资源共享（CORS）：从原理到实践

同源策略与CORS的诞生背景

同源策略（Same-Origin Policy） 是浏览器安全机制的核心组件，它规定只有当协议、域名、端口三者完全相同时才允许资源共享。这种设计有效防范了CSRF（Cross-Site Request Forgery）等攻击，但也给现代分布式系统带来了挑战。CORS（Cross-Origin Resource Sharing）作为W3C标准，通过协商式白名单机制在安全性和灵活性之间取得了平衡。

简单请求与预检请求的深层逻辑

简单请求（Simple Request）的条件

1GET /api/data HTTP/1.1
2Host: api.example.com
3Origin: https://client.com
4Content-Type: text/plain

简单请求必须满足：

1. 方法限制：GET/HEAD/POST
2. 头部白名单：仅允许Accept、Accept-Language、Content-Language、Content-Type
3. Content-Type限制：仅application/x-www-form-urlencoded、multipart/form-data、text/plain

底层机制：浏览器直接发送请求，通过响应头Access-Control-Allow-Origin判断是否允许读取响应体。若未通过验证，浏览器将拦截响应。

预检请求（Preflight Request）流程

sequenceDiagram
    Client->>Server: OPTIONS /api (预检请求)
    Server->>Client: 返回允许的Origin/Methods/Headers
    Client->>Server: 实际请求 (PUT/DELETE等)
    Server->>Client: 实际响应数据

触发条件包含：

• 非简单方法（PUT/DELETE等）
• 自定义头部（如Authorization）
• 非标准Content-Type（如application/json）

技术细节：预检请求的Access-Control-Max-Age可设置缓存时间（单位秒），避免重复预检。

核心响应头深度解析

Access-Control-Allow-Origin

• *通配符仅适用于无凭证请求（without credentials）
• 生产环境建议显式指定域名：Access-Control-Allow-Origin: https://client.com

Access-Control-Allow-Headers

争议点：Safari浏览器不完全支持通配符*，需显式列出所需头部。建议组合配置：

1add_header Access-Control-Allow-Headers $http_access_control_request_headers;

凭证处理

Cookie传输需要双重配置：

1// 客户端
2fetch(url, { credentials: 'include' })
3
4// 服务端
5Access-Control-Allow-Credentials: true
6Access-Control-Allow-Origin: https://client.com  // 禁止使用*

进阶跨域方案对比

文件下载的跨域难题

虽然<a download>属性受同源策略限制，但可通过Blob方案突破：

1fetch('https://cross-origin.com/file', { mode: 'cors' })
2  .then(res => res.blob())
3  .then(blob => {
4    const url = URL.createObjectURL(blob);
5    const a = document.createElement('a');
6    a.href = url;
7    a.download = 'file.pdf';
8    a.click();
9    URL.revokeObjectURL(url);
10  });

安全最佳实践

1. 精确配置白名单：避免使用*，采用动态白名单验证
2. 预检请求缓存优化：合理设置Max-Age（建议≤600秒）
3. 防御CSRF：结合SameSite Cookie和CSRF Token
4. 头部验证：严格校验Origin和Referer头

前沿趋势与挑战

1. CORS in Microservices：服务网格中如何统一管理跨域策略
2. WebAssembly的跨域访问：cross-origin-isolated模式下的新规范
3. Privacy Sandbox：FLoC等新提案对跨域跟踪的影响
4. HTTP/3的挑战：QUIC协议对传统CORS实现的影响

常见陷阱排查

案例1：OPTIONS请求返回200但CORS失败
原因：未正确设置Access-Control-Allow-Headers包含请求中的自定义头部

案例2：Safari浏览器无法识别通配符
解决方案：显式列出允许的头部而非使用*

案例3：带Cookie请求被拦截
验证步骤：

1. 检查credentials: 'include'是否设置
2. 确认服务端返回Access-Control-Allow-Credentials: true
3. 确保Access-Control-Allow-Origin为具体域名

结语

CORS作为现代Web安全的基石，需要开发者深入理解其运行机制。随着Web生态的演进，跨域方案也在不断发展。建议定期查阅Fetch Living Standard和MDN文档，关注W3C工作组动态，在安全与功能之间找到最佳平衡点。