首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >15 张精美动图全面讲解 CORS

15 张精美动图全面讲解 CORS

作者头像
卤代烃
修改2020-08-07 10:16:28
9900
修改2020-08-07 10:16:28
举报
文章被收录于专栏:超级码力超级码力

前言:

本文翻译自 Lydia Hallie[1] 小姐姐写的 ✋?? CS Visualized: CORS[2],她用了大量的动图去解释 CORS 这个概念,国内还没有人翻译本文,所以我在原文的理解上翻译了本文并修改了一些错误,希望能帮到大家。

觉得翻译的不错一定要点赞哦,谢谢你,这对我真的很重要!?

“注:原文的动图均为 keynote 制作

前端开发中,我们经常要使用其他站点的数据。前端显示这些数据之前,必须向服务器发出请求以获取该数据。

假设我们正在访问 https://api.mywebsite.com 这个站点,点击按钮向 https://api.mywebsite.com/users 发送请求,获取网站上的一些用户信息:

“⚠️:这里原作者有个笔误,把 https://api.mywebsite.com 误写为 https://www.mywebsite.com 了,图中也有这个错误,读者要注意一下不要被误导

从结果上看表现非常完美,我们向服务器发送请求,服务器返回了我们需要的 JSON 数据,前端也正常的渲染出了结果。

下面我们换一个网站试试。用 https://www.anotherwebsite.com 这个网站向 https://api.website.com/users 发送请求:

问题来了,我们请求同样的接口网站,但是这次浏览器给我们抛出一个 Error。

刚刚浏览器抛出的就是 CORS Error,下面让我们分析一下为什么会产生这种 Error,以及这个 Error 的确切含义是什么。

1.同源策略

浏览器网络请求时,有一个同源策略的机制。即默认情况下,使用 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源。

比如说, https://www.mywebsite.com 请求 https://www.mywebsite.com/page 是完全没有问题的。但是当资源位于不同协议子域端口的站点时,这个请求就是跨域的。

目前来看,同源策略会让三种行为受限:

  • Cookie、LocalStorage 和 IndexDB 访问受限
  • 无法操作跨域 DOM(常见于 iframe)
  • Javascript 发起的 XHR 和 Fetch 请求受限

那么,为什么会存在同源策略呢?

我们做个假设,如果不存在同源策略,你无意中点击了七大姑在微信上给你发的一篇养生文章链接。其实这个网页是个钓鱼网站,访问链接后就把你重定向到一个嵌入了 iframe 的攻击网站,这个 iframe 会自动加载银行网站,并通过 cookies 登录你的账户。

登陆成功后,这个钓鱼网站还可以控制 iframe 的 DOM,通过一系列骚操作把你卡里的钱转走。

这是一个非常严重的安全漏洞,我们不希望自己在互联网的内容被随便访问,更不要说这种涉及到钱的网站了。

同源策略可以帮助我们解决这个安全问题,这个策略确保我们只能访问同一站点的资源。

在这种情况下,https://www.evilwebsite.com 尝试跨站访问 https://www.bank.com 的资源,同源策略就会阻止这个操作,让钓鱼网站无法访问银行网站的数据。

说了这么多,同源策略和 CORS 又有什么关系?

2.浏览器 CORS

出于安全原因,浏览器限制从脚本内发起的跨域 HTTP 请求。例如 XHR 和 Fetch 就遵循同源策略。这意味着使用 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源。

日常的业务开发中,我们会经常访问跨域资源,为了安全的请求跨域资源,浏览器使用一种称为 CORS 的机制。

CORS 的全名是 Cross-Origin Resource Sharing,即跨域资源共享。尽管默认情况下浏览器禁止我们访问跨域资源,但是我们可以利用 CORS 放宽这种限制,在保证安全性的前提下访问跨域资源。

浏览器可以利用 CORS 机制,放行符合规范的跨域访问,阻止不合规范的跨域访问。浏览器内部是怎么做的呢?我们下面就来分析一下。

Web 程序发出跨域请求后,浏览器会自动向我们的 HTTP header 添加一个额外的请求头字段:OriginOrigin 标记了请求的站点来源:

GET https://api.website.com/users HTTP/1/1
Origin: https://www.mywebsite.com // <- 浏览器自己加的

为了使浏览器允许访问跨域资源, 服务器返回的 response 还需要加一些响应头字段,这些字段将显式表明此服务器是否允许这个跨域请求。

3.服务端 CORS

作为服务器开发人员,我们可以通过在 HTTP 响应中添加额外的响应头字段 Access-Control-* 来表明是否允许跨域请求。根据这些 CORS 响应头字段,浏览器可以允许一些被同源策略限制的跨源响应。

虽然有好几个 CORS 响应头字段[3],但有一个字段是必加的,那就是 Access-Control-Allow-Origin。这个头字段的值指定了哪些站点被允许跨域访问资源。

1️⃣ 如果我们有服务器的开发权限,我们可以给 https://www.mywebsite.com 加上访问权限:将该域添加到 Access-Control-Allow-Origin 中。

这个响应头字段现在被添加到服务器发回给客户端的 response header 中。这个字段添加后,如果我们从 https://www.mywebsite.com 发送跨域请求,同源策略将不再限制 https://api.mywebsite.com 站点返回的资源。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.mywebsite.com
Date: Fri, 11 Oct 2019 15:47 GM
Content-Length: 29
Content-Type: application/json
Server: Apache

{user: [{...}]}

2️⃣ 收到服务器返回的 response 后,浏览器中的 CORS 机制会检查 Access-Control-Allow-Origin 的值是否等于 request 中 Origin 的值。

在这个例子中,request 的 Originhttps://www.mywebsite.com,这和 response 中 Access-Control-Allow-Origin 的值是一样的:

3️⃣ 浏览器校验通过,前端成功地接收到跨域资源。

那么,当我们试图从一个没有在 Access-Control-Allow-Origin 中列出的网站跨域访问这些资源会发生什么呢?

如上图所示,从 https://www.anotherwebsite.com 跨域访问 https://api.mywebsite.com 资源,浏览器抛出一个 CORS Error,经过上面的讲解,我们可以读懂这个报错信息了:

The 'Access-Control-Allow-Origin' header has a value
 'https://www.mywebsite.com' that is not equal 
to the supplied origin. 

在这种情况下,Origin 的值是 https://www.anotherwebsite.com。然而,服务器在 Access-Control-Allow-Origin 响应头字段中没有标记这个站点,浏览器 CORS 机制就阻止了这个响应,我们无法在我们的代码中获取响应数据。

“CORS 还允许我们添加通配符 * 作为允许的外域,这意味着该资源可以被任意外域访问,所以要注意这种特殊情况


Access-Control-Allow-Origin 是 CORS 机制提供的众多头字段之一。服务器开发人员还可以通过其它头字段扩展服务器的 CORS 策略,以允许/禁止某些请求。

另一个常见的响应头字段是 Access-Control-Allow-Methods。其指明了跨域请求所允许使用的 HTTP 方法。

在上图的案例中,只有GETPOSTPUT 方法被允许跨域访问资源。其他 HTTP 方法,例如 PATCHDELETE 都会被阻止。

“如果您想知道其它的 CORS 响应头字段是什么以及它们的用途,可以查看此列表[4]

说到PUTPATCHDELETE 这几个 HTTP 方法,CORS 处理这些方法时还有些不同。这些非简单请求会触发 CORS 的预检请求。

4.预检请求

CORS 有两种类型的请求:一种是简单请求(simple request),一种是预检请求(preflight request)。一个跨域请求到底是简单的的还是预检的,取决于一些 request header。

当请求是 GETPOST 方法并且没有任何自定义 Header 字段时,一般来说就是个简单请求。除此之外的任何请求,诸如 PUTPATCHDELETE 方法,将会产生预检。

“如果你想知道一个请求必须满足哪些要求才能成为简单请求,可以查看 MDN 简单请求相关的文档[5]

说了这么多,「预检请求」到底是什么意思?下面我们就来探讨一下。


1️⃣ 在发送实际请求之前,客户端会先使用 `OPTIONS`[6] 方法发起一个预检请求,预检请求的 Access-Control-Request-* 中包含有关我们将要处理的实际请求的信息:

  • 首部字段 `Access-Control-Request-Method`[7] 告知服务器,实际请求要用到的方法是什么
  • 首部字段 `Access-Control-Request-Headers`[8] 告知服务器,实际请求将附带的自定义请求首部字段是什么
OPTIONS https://api.mywebsite.com/user/1 HTTP/1.1
Origin: https://www.mywebsite.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

2️⃣ 服务器接收到预检请求后,会返回一个没有 body 的 HTTP 响应,这个响应标记了服务器允许的 HTTP 方法和 HTTP Header 字段:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.mywebsite.com
Access-Control-Request-Method: GET POST PUT
Access-Control-Request-Headers: Content-Type

3️⃣ 浏览器收到预检响应,并检查是否应允许发送实际请求。

“⚠️:上图预检响应漏了 Access-Control-Allow-Headers: Content-Type

4️⃣ 如果预检响应检测通过,浏览器会将实际请求发送到服务器,然后服务器返回我们需要的资源。

如果预检响应没有检验通过,CORS 会阻止跨域访问,实际的请求永远不会被发送。预检请求是一种很好的方式,可以防止我们访问或修改那些没有启用 CORS 策略的服务器上的资源。

“? 为了减少网络往返次数,我们可以通过在 CORS 请求中添加 Access-Control-Max-Age 头字段来缓存预检响应。浏览器可以使用缓存来代替发送新的预检请求。

5.认证

XHR 或 Fetch 与 CORS 的一个有趣的特性是,我们可以基于 Cookies[9] 和 HTTP 认证信息发送身份凭证。一般而言,对于跨域 XHR 或 Fetch 请求,浏览器不会发送身份凭证信息。

尽管 CORS 默认情况下不发送身份凭证,但我们可以通过添加 Access-Control-Allow-Credentials CORS 响应头来更改它。

如果要在跨域请求中包含 cookie 和其他授权信息,我们需要做以下操作:

  • XHR 请求中将 withCredentials 字段设置为 true
  • Fetch 请求中将 credentials 设为 include
  • 服务器把 Access-Control-Allow-Credentials: true 添加到响应头中
// 浏览器 fetch 请求
fetch('https://api.mywebsite,com.users', {
  credentials: "include"
})

// 浏览器 XHR 请求
let xhr = new XMLHttpRequest();
xhr.withCredentials = true;

// 服务器添加认证字段
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true

把上面的工作做好后,我们就可以在跨域请求中包含身份凭证信息了。

6.总结

CORS Error 一定程度上会让前端开发很头疼,但是遵循它的相关规定后,它可以让我们在浏览器中进行安全的跨域请求。

同源策略和 CORS 的知识点有很多,本文只讲了一些关键知识点,如果你想全面学习 CORS 的相关知识,我推荐你查阅MDN 文档[10]W3C 规范[11],这些一手知识是最准确的。

7.最后

这篇文章就到此结束了,如果觉得不错的话一定要点赞鼓励一下哦,祝大家学习进步,工作顺利!

参考资料

[1]

Lydia Hallie: https://dev.to/lydiahallie

[2]

✋?? CS Visualized: CORS: https://dev.to/lydiahallie/cs-visualized-cors-5b8h?utm_campaign=React%2BNative%2BNow&utm_medium=web&utm_source=React_Native_Now_69#cs-cors

[3]

好几个 CORS 响应头字段: https://fetch.spec.whatwg.org/#http-responses

[4]

查看此列表: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#The_HTTP_response_headers

[5]

文档: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Simple_requests

[6]

OPTIONS: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/OPTIONS

[7]

Access-Control-Request-Method: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Request-Method

[8]

Access-Control-Request-Headers: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Request-Headers

[9]

Cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

[10]

MDN 文档: https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

[11]

W3C 规范: https://www.w3.org/wiki/CORS_Enabled

[12]

X-Forwarded-For 拿到的就是真实 IP 吗?: https://juejin.im/post/6844904174132396045

[13]

HTTP 请求中,空格应该被编码为 %20 还是 + ?: https://juejin.im/post/6844904178267979783

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-08-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 卤蛋实验室 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言:
  • 1.同源策略
  • 2.浏览器 CORS
  • 3.服务端 CORS
  • 4.预检请求
  • 5.认证
  • 6.总结
  • 7.最后
    • 参考资料
    相关产品与服务
    云服务器
    云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档