什么是 CORS？

过去，在互联网技术刚刚出现的时候，跨站请求伪造 (CSRF) 的问题时有发生。这些问题将虚假的客户端请求从受害者的浏览器发送到另一个应用程序。

例如，受害者登录了其银行的应用程序。然后，他们被诱骗在新的浏览器选项卡上加载外部网站。然后，外部网站使用受害者的 Cookie 凭证并将数据中继到银行应用程序，同时假装自己是受害者。然后，未经授权的用户就可以意外访问银行应用程序。

为了防止此类 CSRF 问题，所有浏览器现在都实施同源策略。

同源策略

如今，浏览器强制要求客户端只能向与客户端 URL 具有相同来源的资源发送请求。客户端 URL 的协议、端口和主机名都应与其请求的服务器相匹配。

例如，考虑以下 URL 与客户端 URL http://store.aws.com/dir/page.html 的来源比较。

URL	结果	原因
http://store.aws.com/dir2/new.html	来源相同	只有路径不同
http://store.aws.com/dir/inner/other.html	来源相同	只有路径不同
https://store.aws.com/page.html	来源不同	协议不同
http://store.aws.com:81/dir/page.html	来源不同	端口不同（默认情况下，http:// 的端口号为 80）
http://news.aws.com/dir/page.html	来源不同	主机不同

因此，对于真正的用例来说，同源策略非常安全，但却不够灵活。

跨源资源共享 (CORS) 是同源策略的扩展。您需要它来与外部第三方共享授权的资源。例如，当您想从公共或授权的外部 API 中提取数据时，就需要 CORS。如果您想允许授权的第三方访问您自己的服务器资源，也需要 CORS。

在 HTTP 中，请求方法是客户端希望服务器执行的数据操作。常用的 HTTP 方法包括 GET、POST、PUT 和 DELETE。

在常规的跨源资源共享 (CORS) 交互中，浏览器会同时发送请求和访问控制标头。这些请求通常是 GET 数据请求，被认为是低风险的。

但是，有些 HTTP 请求被认为很复杂，需要服务器确认才能发送实际请求。这个预先批准过程被称为预检请求。

复杂的跨源请求

如果跨源请求使用以下任何一项，则会很复杂：

• GET、POST 或 HEAD 以外的方法
• Accept-Language、Accept 或 Content-Language 以外的标头
• multipart/form-data、application/x-www-form-urlencoded 或 text/plain 以外的内容类型标头

因此，例如，删除或修改现有数据的请求被认为是复杂的。

预检请求的工作原理

如果需要，浏览器会创建预检请求。这是一个 OPTIONS 请求，如下所示。

OPTIONS /data HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: DELETE

浏览器在实际请求消息之前发送预检请求。服务器必须使用服务器愿意从客户端 URL 接受的跨源请求的相关信息来响应预检请求。服务器响应标头必须包含以下内容：

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

下面给出了服务器响应示例。

HTTP/1.1 200 OK Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

预检响应有时会另外包含 Access-Control-Max-Age 标头。该指标为浏览器指定在其中缓存预检结果的持续时间（以秒为单位）。缓存允许浏览器在预检请求之间发送多个复杂的请求。在 max-age 指定的时间结束之前，它不必再次发送预检请求。

 

在服务器上配置跨源资源共享 (CORS) 时，应注意以下几点。

定义合适的访问权限列表

最好使用逗号分隔列表来授予对单个域的访问权限。除非您想公开 API，否则请避免使用通配符。如若不然，使用通配符和正则表达式可能会产生漏洞。

例如，假设您编写了一个正则表达式，该正则表达式授予对所有后缀为 permitted-website.com 的网站的访问权限。通过一个表达式即可授予对 api.permitted-website.com 和 news.permitted-website.com 的访问权限。但是，您也无意中授予了对未经授权的网站的访问权限，这些网站可能使用诸如 maliciouspermitted-website.com 之类的域名。

避免在列表中使用 null 来源

对于某些场景，例如文件请求或来自本地主机的请求，某些浏览器会在请求标头中发送 null 值。

但是，您不应在访问权限列表中包含 null 值。这样也会带来安全风险，因为包含 null 标头的未经授权的请求可能会获得访问权限。