摘要

  • W3C 2007 年的草案开始研究由资源主人放宽跨站读取限制；2009 年的 CORS 草案把发起页的 Origin、资源的许可响应和浏览器的检查串成更明确的流程。
  • 2014 年的 W3C 推荐标准规定了 Access-Control-Allow-Origin 的检查。某些方法或自定义请求头需要先发 OPTIONS 预检；普通跨源请求即使到达服务器，脚本也未必能读取返回内容。

想象一张天气图，气温数据在另一家网站。地图的脚本知道门牌号，网络也能把请求送过去。浏览器却不能因此把隔壁屋里的回信随手递给它。同源边界保护的是脚本读取另一来源响应的能力。CORS 给资源的主人一支笔，让他自己写收件人；浏览器负责核对字迹。

W3C 2007 年 2 月 15 日的《Enabling Read Access for Web Resources》草案已经提出：资源作者可通过 HTTP 头或 XML 处理指令，允许原本受限的跨站读取。那时还在尝试不同的主机匹配写法，远未定型；但权限从资源一侧发出这一点已经清楚。2009 年 3 月 17 日的 CORS 工作草案继续把这场对话具体化：发起请求的一方说明自己的 Origin，资源在响应里给出允许范围，浏览器照规则判断。

到2014 年 1 月 16 日的 W3C 推荐标准，请柬上的名字成了 Access-Control-Allow-Origin。资源可以填入获准来源；浏览器把它与发起页的来源比对，决定是否把响应内容交给页面脚本。公开、无凭据的资源可用 * 允许更广泛的读取。若请求带着凭据，规则要求相符的具体来源，以及 Access-Control-Allow-Credentials: true。把所有人都请进大厅，与允许某位客人进入私人房间，是两回事。

有的客人还要先敲门。脚本想使用不属于简单集合的方法或自设请求头时，浏览器先发 OPTIONS 预检，询问对方允许哪些方法、哪些头。答复合格，主要请求才继续；预检结果还可能暂时缓存。并非每次跨源通信都有这道序幕。把所有 CORS 失败都怪到预检头上，像把每次邻里争吵都怪到门铃上，显然看漏了人。

最重要的分界藏在请求与回信之间。普通的跨源请求可能已经到达服务器，甚至触发了服务器端动作；浏览器随后仍可能不让页面脚本读取响应。2014 年文件的安全讨论明确区分了“批准请求及其副作用”和“批准读取返回内容”。服务器必须自己判断用户有没有权执行转账、改密码或其他动作。CORS 的许可响应只是浏览器的读信规则，不替服务器保管保险柜钥匙。

W3C 的 CORS 发布沿革把 2007 年的试探、2014 年推荐标准发布公告和该文件 2020 年退役串了起来。回看这段历史，改变并不玄妙：资源主人可以精确表态，浏览器可以代为执行，网页可以在获准后使用隔壁数据。天气图终于画出一条线，而隔壁家没有把整串钥匙交出来。