关于CORS，你了解的并不一定是对的？

CORS&＃xff0c;有时候面试的也会问到。

如果你和我一样&＃xff0c;第一次遇到 CORS &＃xff08;跨域资源共享&＃xff09;&＃xff0c;你想让服务器接收那些你拼接的 Ajax 请求并处理他们。所以你去 stackoverflow.com 复制一段代码来设置一些 HTTP Headers&＃xff0c;让请求可以正常工作。

但是&＃xff0c;可能还有一些事情你应该知道。

CORS 是什么&＃xff0c;不是什么

新手通常混淆的原因&＃xff0c;就是因为他们并不明确 CORS 能做什么。首先&＃xff0c;CORS 并不是一种安全措施&＃xff0c;实际上恰恰相反&＃xff1a;CORS 是一种绕过“同源策略(SOP)”的方法。同源策略是一种安全措施&＃xff0c;阻止您向其他域发出Ajax请求。

同源策略声明一个域上的网站&＃xff0c;无法向另一个域发出 XMLHttpRequest(XHR) 请求。这可以防止恶意网站向已知网站&＃xff08;比如 Facebook 或者 Google&＃xff09;发出请求&＃xff0c;改变用户的登录状态&＃xff0c;以便可以冒充其他用户。此策略由浏览器实现&＃xff08;所有浏览器都实现了同源策略&＃xff0c;尽管实现细节上存在细微的差别&＃xff09;&＃xff0c;这意味着此策略并不适用于从服务器&＃xff0c;或者任何其他HTTP客户端&＃xff08;比如 cURL &＃xff0c;postman&＃xff09;发出的请求。此外&＃xff0c;服务器同样无法完全控制它&＃xff1a;服务器将处理每个请求&＃xff0c;并假设他们都来自可信域&＃xff0c;请求是否会被阻止完全取决于浏览器。

同源策略绝不意味着防止攻击者向您的服务器发出请求&＃xff08;因为攻击者显然不会使用浏览器&＃xff09;。它只是为了防止合法用户在使用知名浏览器浏览网站时&＃xff0c;在不知情的情况下&＃xff0c;向你的网站发起请求。

CORS 是一种绕过同源策略的方法&＃xff0c;在某些情况下&＃xff0c;您希望一些特殊的站点可以向你的服务器发起请求&＃xff0c;即使正常情况下它会被阻止。&＃xff08;通常&＃xff0c;是允许您的前端应用向您的API发出请求&＃xff09;。

CORS 是如何工作的

与HTTP的相同&＃xff0c;CORS基本上也是浏览器和服务器之间的对话。假设你前端的域名为 domain-a.com &＃xff0c;后端API的域名为 domain-b.com&＃xff0c;对话会是这样的&＃xff1a;

• 浏览器&＃xff1a;“Hey domain-b.com&＃xff0c;domain-a.com上的这个脚本要向你发起一次Ajax请求&＃xff0c;但是我应该阻止它&＃xff0c;除非你告诉我这个请求是没问题的。”

• 服务器&＃xff1a;“我不知道&＃xff0c;但是我可以告诉你&＃xff0c;https://domain-a.com 只允许发送 GET&＃xff0c;POST&＃xff0c;OPTIONS 和 DELETE 请求&＃xff0c;并且需要每10分钟验证一次。”

浏览器想了想&＃xff1a;“ yeah&＃xff0c;这是个正确的域名&＃xff0c;我应该给他发送请求。”

• 浏览器&＃xff1a;“Hey domain-b.com&＃xff0c;我想在这个终端向你发送 POST 请求。”

• 服务器&＃xff1a;“没问题&＃xff0c;这是你的 200 ”

或者&＃xff0c;如果用户位于不同的域&＃xff0c;则对话会更短&＃xff1a;

• 浏览器&＃xff1a;“Hey domain-b.com&＃xff0c;malicious-domain.com&＃xff08;恶意站点&＃xff09;上的这个脚本要向你发起一次Ajax请求&＃xff0c;但是我应该阻止它&＃xff0c;除非你告诉我这个请求是没问题的。”

• 服务器&＃xff1a;“我不知道&＃xff0c;但是我可以告诉你&＃xff0c;https://domain-a.com 只允许发送 GET&＃xff0c;POST&＃xff0c;OPTIONS 和 DELETE 请求&＃xff0c;并且需要每10分钟验证一次。”

浏览器想了想&＃xff1a;“ Oh&＃xff0c;这不是正确的域名&＃xff0c;我们最好不要发送请求”&＃xff0c;然后在控制台打印了错误。
译注&＃xff1a;第二种&＃xff0c;使用开发者工具查看时&＃xff0c;看不到 Response Headers&＃xff0c;但是可以看到下图中的提示

在浏览器中的样子

在上面的小场景中&＃xff0c;浏览器提出的第一个问题称为 预检请求&＃xff0c;对应的 HTTP 谓词是 OPTIONS。遇到这种预检请求&＃xff0c;服务器应该总是返回一个 200 的响应&＃xff0c;没有正文&＃xff0c;但是会包含 Access-Control-Allow-Origin &＃xff0c;以及一些其他响应头。在我们的示例中响应头如下&＃xff1a;

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://domain-a.comAccess-Control-Allow-Methods: GET, POST, OPTIONS, DELETE
Access-Control-Max-Age: 3600

它告诉浏览器&＃xff0c;它只能响应来自 domain-a.com 的请求&＃xff0c;可以处理 GET, POST, OPTIONS 或者 DELETE 请求&＃xff08;PUT 请求会被阻止&＃xff09;&＃xff0c;并且他可以缓存此信息 3600 秒&＃xff0c;所以它不需要都发起一个新的 OPTIONS 请求。

当然&＃xff0c;如果我们使用其他域名&＃xff0c;这将不起作用。浏览器会发送 OPTIONS 请求&＃xff0c;然后在控制台中抛出异常&＃xff0c;并且永远不会发送 POST 请求。

很直接&＃xff0c;对吧&＃xff1f;

但是&＃xff0c;也存在一些陷阱…

关于 CORS 的棘手问题

所求请求都包含 CORS 头&＃xff08;headers&＃xff09;

您可能会认为&＃xff0c;如果您的服务器响应 OPTIONS 请求时返回 200&＃xff0c;然后你将这些正确的响应头去掉。然后你将看到浏览器先发送了 OPTIONS 请求&＃xff0c;然后发送了其他请求&＃xff0c;其他请求挂掉了… 这是因为每个请求&＃xff08;GET, POST, 或者其他请求&＃xff09;都应该包含相同的响应头&＃xff1a;“Access-Control-Allow-Headers”。

并非所有请求都会触发预检请求

有一些请求不会触发预检请求&＃xff0c;比如 GET 请求&＃xff0c;或者 Content-Type 设置为 application/x-www-form-urlencoded 的 POST 请求。这些是浏览器一直允许的“简单请求”&＃xff0c;&＃xff08;即使在CORS不支持的情况下&＃xff0c;你依然可以使用超链接&＃xff08;a标签&＃xff09;或者使用 POST 请求向其他网站提供表单&＃xff0c;您可以在此处找到完整列表。在 POST 请求的情况下&＃xff0c;结果会有些违反直觉&＃xff1a;浏览器将发出 POST 请求&＃xff08;因此您的服务器可能会保留一些数据&＃xff09;&＃xff0c;然后忽略响应。

在传统的Web应用程序中&＃xff0c;您可以使用 application/json 作为 content-type&＃xff0c;因此会有预检请求&＃xff0c;但请记住&＃xff0c;您的服务器可能仍会收到来自其他域的 POST 请求&＃xff0c;因此请不要盲目接受它们。

被允许的域名必须包含协议

您不能只将 mydomain.com 当做域名使用&＃xff0c;它还需要包含协议&＃xff0c;&＃xff08;例如&＃xff1a;https://mydomain.com&＃xff09;。有趣的是&＃xff0c;你不能同时接收 http 和 https &＃xff0c;因为……

您只能允许一个域

您可以使用 Access-Control-Allow-Origin: * 来允许每个域访问&＃xff0c;也可以只允许一个域访问。这意味着如果您需要多个域来访问您的API时&＃xff0c;您需要自己处理它。

处理此问题的最简单方法是在服务器上维护允许访问的域列表&＃xff0c;如果域位于该列表中&＃xff0c;则动态的改变响应头的内容。下面是一个 PHP 的例子&＃xff1a;

$allowedDomains &＃61; ["http://www.mydomain.com","https://www.mydomain.com","http://www.myotherdomain.com","http://www.myotherdomain.com",];$originDomain &＃61; $_SERVER[&＃39;HTTP_ORIGIN&＃39;];if (in_array($originDomain, $allowedDomains)) {header("Access-Control-Allow-Origin: $originDomain");};

或者 Node.js 的例子

app.use(function(req, res, next) {const allowedOrigins &＃61; ["http://www.mydomain.com","https://www.mydomain.com","http://www.myotherdomain.com","http://www.myotherdomain.com",];const origin &＃61; req.headers.origin;if(allowedOrigins.indexOf(origin) > -1){res.setHeader(&＃39;Access-Control-Allow-Origin&＃39;, origin);}return next();});

同源策略适用于 Chrome 和 Safari 的文件系统&＃xff0c;不适用于 Firefox 的

如果您向本地文件发出请求&＃xff0c;Firefox会认为它始终位于同一个域上并允许该请求。基于 Webkit 的浏览器&＃xff08;如Chrome或Safari&＃xff09;会将此视为安全风险&＃xff0c;并阻止对本地文件的Ajax查询。解决这个问题的唯一方法是使用Firefox&＃xff0c;或安装将发送 Access-Control-Allow-Origin: * 响应头的Web服务器。正如 &＃64;brianjenkins94 在评论中指出的那样&＃xff0c;您也可以用 —disable-web-security 参数来启动Chrome 。

iOS WKWebview需要CORS

如果您正在开发使用 webview&＃xff08;使用Cordova或Ionic&＃xff09;的移动应用程序&＃xff0c;Android将不会给您带来任何麻烦&＃xff0c;但iOS上的新 WKWebview 将需要CORS。这意味着您几乎必须始终将 Access-Control-Allow-Origin 标头设置为 * &＃xff0c;但实际上这并不理想。

另一个选择是不在您的应用程序中发出Ajax请求并使用 cordova 插件来生成本机 http 请求&＃xff0c;这将很方便的绕过同源策略。

谢谢阅读 &＃xff01;
如果您想要更深入地了解CORS&＃xff0c;请访问MDN&＃xff1a;https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

关于本文
译者&＃xff1a;&＃64;joking_zhang
译文&＃xff1a;https://segmentfault.com/a/1190000019824580
作者&＃xff1a;&＃64;Nicolas Bailly
原文&＃xff1a;https://dev.to/nicolus/what-you-should-know-about-cors-48d6

最后

看完点个赞&＃xff0c;分享一下吧&＃xff0c;让更多的朋友能够看到。如果你喜欢前端开发博客的分享&＃xff0c;就给公号标个星吧&＃xff0c;这样就不会错过我的文章了。

好文和朋友一起看~