CORS（跨域资源共享）

CORS(Cross-Origin Resource Sharing,跨域资源共享)是一种基于 HTTP 头的浏览器安全机制,允许服务器声明哪些「外来源」的网页可以访问自己的资源,从而在保证安全的前提下有条件地绕过同源策略的限制。

概述

浏览器默认执行「同源策略」:只有协议、域名、端口三者完全相同的两个地址才算同源,网页中的脚本默认只能读取同源服务器返回的数据。这一策略能防止恶意网站偷读用户在其他网站上的信息,但也把正常的跨站调用一并挡住了——比如前端页面部署在一个域名,而接口 API 部署在另一个域名,这在前后端分离架构中非常普遍。

CORS 就是为解决这个矛盾而设计的标准:浏览器发起跨域请求时会自动附带 Origin 请求头标明来源,服务器则通过 Access-Control-Allow-Origin 等响应头回答「是否允许这个来源访问」。浏览器收到响应后进行校验,允许则把数据交给页面脚本,不允许则拦截并在控制台报错。整个过程由浏览器自动完成,该机制现已并入 WHATWG 的 Fetch 标准,被主流浏览器普遍支持。

工作方式与核心要点

• 简单请求:如普通的 GET、POST 表单类请求,浏览器直接发送,再根据响应头判断是否放行结果。
• 预检请求:带自定义头、发送 JSON 等「复杂请求」,浏览器会先发一个 OPTIONS 请求探路,服务器确认允许后才发送真正的请求。
• 常用响应头:Access-Control-Allow-Origin(允许的来源)、Allow-Methods(允许的方法)、Allow-Headers(允许的请求头)、Allow-Credentials(是否允许携带 Cookie)等。
• 凭证限制:请求需要携带 Cookie 时,允许来源不能写通配符 *,必须指明具体域名。

常见问题

问:控制台出现 CORS 报错,应该由前端还是后端解决?答:根源在服务器端,需要后端(或网关、反向代理)配置允许的来源等响应头;前端在开发阶段也可用代理临时绕过,但上线仍要靠服务端配置。

问:CORS 报错时请求真的没发出去吗?答:不一定。很多情况下请求已到达服务器并被处理,只是浏览器拦截了响应、不把数据交给页面脚本,因此不能把 CORS 当作服务端的安全防线。

问:CORS 和 JSONP 有什么区别?答:JSONP 是早年利用 script 标签实现跨域的变通手段,只支持 GET 且有安全隐患;CORS 是官方标准,支持各类 HTTP 方法和精细的权限控制,是现在的首选方案。