同源策略与跨域资源共享（CORS）详解
字数 1930 2025-11-11 12:17:09

同源策略与跨域资源共享（CORS）详解

一、问题描述

在Web安全中，同源策略（Same-Origin Policy） 是浏览器最核心的安全机制之一，它限制不同源的文档或脚本对当前文档的资源进行跨域访问。但实际开发中，跨域请求是常见需求（例如前后端分离架构），因此需要一种安全且可控的跨域机制——CORS（Cross-Origin Resource Sharing）。面试中常考察以下问题：

  1. 同源策略的定义与限制范围？
  2. CORS如何实现跨域请求？其安全机制如何工作？
  3. 简单请求与非简单请求的区别？预检请求（Preflight）的作用？
  4. 常见CORS配置错误会导致哪些安全风险？

二、同源策略的基本原理

1. 什么是“同源”？

如果两个URL的协议（Protocol）、域名（Host）、端口（Port） 完全相同，则视为同源。例如：

  • https://example.com/app1 和 https://example.com/app2 同源（协议、域名、端口一致）。
  • https://example.com 和 http://example.com 不同源（协议不同）。
  • https://example.com 和 https://api.example.com 不同源（域名不同）。

2. 同源策略的限制行为

浏览器禁止跨域操作包括：

  • DOM访问：不同源的脚本无法读取对方的DOM、Cookie、LocalStorage。
  • Ajax请求拦截：通过XMLHttpRequest或fetch发起的跨域请求会被浏览器阻塞（但请求实际可能到达服务器）。
  • 注意：某些标签（如<img>、<script>）允许跨域加载资源，但无法读取响应内容。

三、CORS的工作原理

CORS通过HTTP响应头告知浏览器允许某些跨域请求。

1. 简单请求（Simple Request）

需同时满足以下条件：

  • 方法为GET、POST、HEAD之一。
  • 请求头仅包含以下字段：Accept、Accept-Language、Content-Language、Content-Type（值限于application/x-www-form-urlencoded、multipart/form-data、text/plain）。

流程示例：

  1. 浏览器发送跨域请求，自动在请求头中添加Origin: https://site-a.com。
  2. 服务器响应需包含头： 
    Access-Control-Allow-Origin: https://site-a.com  // 或 *（允许任意源）
  3. 浏览器检查Access-Control-Allow-Origin是否匹配当前源，若匹配则允许访问响应。

2. 非简单请求（Preflight Request）

当请求不满足简单请求条件时（例如使用PUT方法或自定义头X-API-Key），浏览器会先发送预检请求（OPTIONS方法）。

流程示例：

  1. 浏览器发送OPTIONS请求，头中包含： 
    Origin: https://site-a.com  
Access-Control-Request-Method: PUT  
Access-Control-Request-Headers: X-API-Key
  2. 服务器响应需包含： 
    Access-Control-Allow-Origin: https://site-a.com  
Access-Control-Allow-Methods: PUT, POST  
Access-Control-Allow-Headers: X-API-Key
  3. 浏览器确认响应合法后，才发送实际请求。

四、CORS的安全机制与风险

1. 凭证与CORS

默认情况下，CORS请求不携带Cookie等凭证信息。若需携带，需满足：

  • 请求设置credentials: include（fetch API）或withCredentials: true（XHR）。
  • 服务器响应头必须为具体域名（不能为*），且需包含： 
    Access-Control-Allow-Credentials: true

2. 常见配置错误与风险

  • 滥用Access-Control-Allow-Origin: *：若响应含敏感数据且允许凭证，*会导致浏览器拒绝请求，但若未校验Origin头，攻击者可伪造请求源。
  • 反射Origin头：直接返回请求中的Origin值而不校验白名单，可能被攻击者利用恶意网站发起跨域请求。
  • 过度放宽Access-Control-Allow-Methods：允许不必要的HTTP方法（如DELETE）会增加攻击面。

五、防御最佳实践

  1. 严格限制允许的源： 
    # Nginx配置示例  
add_header Access-Control-Allow-Origin https://trusted-site.com;
  2. 避免动态反射Origin：校验Origin头是否在预定义白名单中。
  3. 最小化允许的方法和头：仅配置必要的Access-Control-Allow-Methods和Access-Control-Allow-Headers。
  4. 敏感接口避免CORS：关键操作建议限制为同源访问。

六、总结

同源策略是浏览器的安全基石，而CORS是其合理补充。正确配置CORS需理解简单请求/预检请求的触发条件、凭证要求及服务器响应头的含义。错误配置可能导致数据泄露或CSRF变种攻击，因此需遵循最小权限原则。

同源策略与跨域资源共享（CORS）详解 一、问题描述 在Web安全中， 同源策略（Same-Origin Policy） 是浏览器最核心的安全机制之一，它限制不同源的文档或脚本对当前文档的资源进行跨域访问。但实际开发中，跨域请求是常见需求（例如前后端分离架构），因此需要一种安全且可控的跨域机制—— CORS（Cross-Origin Resource Sharing） 。面试中常考察以下问题： 同源策略的定义与限制范围？ CORS如何实现跨域请求？其安全机制如何工作？ 简单请求与非简单请求的区别？预检请求（Preflight）的作用？ 常见CORS配置错误会导致哪些安全风险？ 二、同源策略的基本原理 1. 什么是“同源”？ 如果两个URL的 协议（Protocol）、域名（Host）、端口（Port） 完全相同，则视为同源。例如： https://example.com/app1 和 https://example.com/app2 同源 （协议、域名、端口一致）。 https://example.com 和 http://example.com 不同源 （协议不同）。 https://example.com 和 https://api.example.com 不同源 （域名不同）。 2. 同源策略的限制行为 浏览器禁止跨域操作包括： DOM访问 ：不同源的脚本无法读取对方的DOM、Cookie、LocalStorage。 Ajax请求拦截 ：通过 XMLHttpRequest 或 fetch 发起的跨域请求会被浏览器阻塞（但请求实际可能到达服务器）。 注意：某些标签（如 <img> 、 <script> ）允许跨域加载资源，但无法读取响应内容。 三、CORS的工作原理 CORS通过 HTTP响应头 告知浏览器允许某些跨域请求。 1. 简单请求（Simple Request） 需同时满足以下条件： 方法为 GET 、 POST 、 HEAD 之一。 请求头仅包含以下字段： Accept 、 Accept-Language 、 Content-Language 、 Content-Type （值限于 application/x-www-form-urlencoded 、 multipart/form-data 、 text/plain ）。 流程示例： 浏览器发送跨域请求，自动在请求头中添加 Origin: https://site-a.com 。 服务器响应需包含头： 浏览器检查 Access-Control-Allow-Origin 是否匹配当前源，若匹配则允许访问响应。 2. 非简单请求（Preflight Request） 当请求不满足简单请求条件时（例如使用 PUT 方法或自定义头 X-API-Key ），浏览器会先发送 预检请求（OPTIONS方法） 。 流程示例： 浏览器发送OPTIONS请求，头中包含： 服务器响应需包含： 浏览器确认响应合法后，才发送实际请求。 四、CORS的安全机制与风险 1. 凭证与CORS 默认情况下，CORS请求不携带Cookie等凭证信息。若需携带，需满足： 请求设置 credentials: include （fetch API）或 withCredentials: true （XHR）。 服务器响应头必须为具体域名（不能为 * ），且需包含： 2. 常见配置错误与风险 滥用 Access-Control-Allow-Origin: * ：若响应含敏感数据且允许凭证， * 会导致浏览器拒绝请求，但若未校验 Origin 头，攻击者可伪造请求源。 反射Origin头 ：直接返回请求中的 Origin 值而不校验白名单，可能被攻击者利用恶意网站发起跨域请求。 过度放宽 Access-Control-Allow-Methods ：允许不必要的HTTP方法（如 DELETE ）会增加攻击面。 五、防御最佳实践 严格限制允许的源 ： 避免动态反射Origin ：校验 Origin 头是否在预定义白名单中。 最小化允许的方法和头 ：仅配置必要的 Access-Control-Allow-Methods 和 Access-Control-Allow-Headers 。 敏感接口避免CORS ：关键操作建议限制为同源访问。 六、总结 同源策略是浏览器的安全基石，而CORS是其合理补充。正确配置CORS需理解简单请求/预检请求的触发条件、凭证要求及服务器响应头的含义。错误配置可能导致数据泄露或CSRF变种攻击，因此需遵循最小权限原则。