了解 CORS 在 Web 浏览器中的工作原理

CORS（跨源资源共享）是浏览器通过HTTP标头机制控制跨域资源请求的安全功能，其核心目的是在允许合法跨域交互的同时防止恶意网站窃取敏感数据。 以下是其工作原理的详细说明：

一、CORS的核心机制

同源策略（SOP）的突破浏览器默认实施同源策略，禁止网页向不同域（协议、域名、端口任一不同）发起请求。CORS通过服务器声明允许的跨域来源，在安全框架内开放特定资源访问权限。
HTTP标头控制服务器通过响应标头明确告知浏览器哪些跨域请求被允许，关键标头包括：
Access-Control-Allow-Origin指定允许访问资源的域（如
https://example.com
），或通配符*（仅限公开资源）。
Access-Control-Allow-Methods声明允许的HTTP方法（如GET, POST, PUT）。
Access-Control-Allow-Headers列出实际请求可包含的自定义标头（如Content-Type, Authorization）。
Access-Control-Allow-Credentials若设置为true，允许跨域请求携带Cookie或HTTP认证信息。

二、CORS的完整工作流程

简单请求的直接处理当请求满足以下条件时，浏览器直接发送请求，无需预检：
方法为GET、POST或HEAD；
仅使用安全标头（如Accept、Content-Type等）；
未使用自定义标头。示例：
fetch('
https://api.example.com/data'
) .then(response => response.json()) .then(data => console.log(data));
服务器响应需包含Access-Control-Allow-Origin:
https://example.com
，否则浏览器拦截响应。
复杂请求的预检机制若请求包含以下任一情况，浏览器先发送OPTIONS预检请求：
使用PUT、DELETE等方法；
包含自定义标头（如X-Requested-With）；
Content-Type为application/json等非简单类型。预检请求示例：
OPTIONS /update HTTP/1.1Origin:
https://example.comAccess-Control-Request-Method:
PUTAccess-Control-Request-Headers: Content-Type
服务器需响应预检标头，确认允许实际请求：Access-Control-Allow-Origin:
https://example.comAccess-Control-Allow-Methods:
PUTAccess-Control-Allow-Headers: Content-Type
预检通过后，浏览器发送实际请求；否则终止流程。
浏览器最终决策浏览器检查服务器响应标头：
若标头缺失、不匹配或包含无效值（如Access-Control-Allow-Origin与当前域不符），则抛出CORS错误。
仅当所有标头均符合要求时，浏览器才将响应数据传递给网页。

三、CORS的重要性

安全防护防止CSRF（跨站请求伪造）等攻击，确保资源仅被授权域访问。例如，恶意网站无法通过<img>标签或XMLHttpRequest窃取用户银行账户数据。
灵活的资源共享支持合法跨域场景，如：
前端应用调用第三方API（如天气服务）；
微服务架构中不同域的服务间通信；
CDN加速静态资源加载。
细粒度控制服务器可针对不同来源、方法或标头设置差异化策略，例如：
允许GET请求来自任何域，但POST仅限特定域；
仅允许携带认证信息的请求访问敏感接口。

四、常见问题与解决

CORS错误排查
错误表现：浏览器控制台显示No 'Access-Control-Allow-Origin' header或Preflight response did not succeed。
解决方案：
确保服务器响应包含正确的CORS标头；
检查预检请求是否被服务器拦截；
避免在开发环境中使用通配符*与凭据（credentials: true）混用。
开发环境优化
使用代理服务器（如Webpack DevServer的proxy配置）绕过CORS限制；
临时关闭浏览器安全策略（仅限测试环境）。

五、总结

CORS通过标准化HTTP标头，在浏览器与服务器间建立安全通信协议。其设计兼顾了安全性与灵活性，成为现代Web开发中不可或缺的基础设施。开发者需深入理解其机制，合理配置服务器标头，以平衡资源开放与数据保护的需求。

热门标签