15 張精美動(dòng)圖全面講解 CORS
前言：
本文翻譯自 Lydia Hallie[1] 小姐姐寫的 ??? CS Visualized: CORS[2]，她用了大量的動(dòng)圖去解釋 CORS 這個(gè)概念，國內(nèi)還沒有人翻譯本文，所以我在原文的理解上翻譯了本文并修改了一些錯(cuò)誤，希望能幫到大家。
覺得翻譯的不錯(cuò)一定要點(diǎn)贊哦，謝謝你，這對(duì)我真的很重要！?
“注：原文的動(dòng)圖均為 keynote 制作
前端開發(fā)中，我們經(jīng)常要使用其他站點(diǎn)的數(shù)據(jù)。前端顯示這些數(shù)據(jù)之前，必須向服務(wù)器發(fā)出請求以獲取該數(shù)據(jù)。
假設(shè)我們正在訪問 https://api.mywebsite.com 這個(gè)站點(diǎn)，點(diǎn)擊按鈕向 ?https://api.mywebsite.com/users 發(fā)送請求，獲取網(wǎng)站上的一些用戶信息：
“??：這里原作者有個(gè)筆誤，把
https://api.mywebsite.com誤寫為https://www.mywebsite.com了，圖中也有這個(gè)錯(cuò)誤，讀者要注意一下不要被誤導(dǎo)
從結(jié)果上看表現(xiàn)非常完美，我們向服務(wù)器發(fā)送請求，服務(wù)器返回了我們需要的 JSON 數(shù)據(jù)，前端也正常的渲染出了結(jié)果。
下面我們換一個(gè)網(wǎng)站試試。用 ?https://www.anotherwebsite.com 這個(gè)網(wǎng)站向 https://api.website.com/users 發(fā)送請求：
問題來了，我們請求同樣的接口網(wǎng)站，但是這次瀏覽器給我們拋出一個(gè) Error。
剛剛瀏覽器拋出的就是 CORS Error，下面讓我們分析一下為什么會(huì)產(chǎn)生這種 Error，以及這個(gè) Error 的確切含義是什么。
1.同源策略
瀏覽器網(wǎng)絡(luò)請求時(shí)，有一個(gè)同源策略的機(jī)制。即默認(rèn)情況下，使用 API 的 Web 應(yīng)用程序只能從加載應(yīng)用程序的同一個(gè)域請求 HTTP 資源。
比如說， https://www.mywebsite.com 請求 ?https://www.mywebsite.com/page 是完全沒有問題的。但是當(dāng)資源位于不同協(xié)議、子域或端口的站點(diǎn)時(shí)，這個(gè)請求就是跨域的。
目前來看，同源策略會(huì)讓三種行為受限：
Cookie、LocalStorage 和 IndexDB 訪問受限 無法操作跨域 DOM（常見于 iframe） Javascript 發(fā)起的 XHR 和 Fetch 請求受限
那么，為什么會(huì)存在同源策略呢？
我們做個(gè)假設(shè)，如果不存在同源策略，你無意中點(diǎn)擊了七大姑在微信上給你發(fā)的一篇養(yǎng)生文章鏈接。其實(shí)這個(gè)網(wǎng)頁是個(gè)釣魚網(wǎng)站，訪問鏈接后就把你重定向到一個(gè)嵌入了 iframe 的攻擊網(wǎng)站，這個(gè) iframe 會(huì)自動(dòng)加載銀行網(wǎng)站，并通過 cookies 登錄你的賬戶。
登陸成功后，這個(gè)釣魚網(wǎng)站還可以控制 iframe 的 DOM，通過一系列騷操作把你卡里的錢轉(zhuǎn)走。
這是一個(gè)非常嚴(yán)重的安全漏洞，我們不希望自己在互聯(lián)網(wǎng)的內(nèi)容被隨便訪問，更不要說這種涉及到錢的網(wǎng)站了。
同源策略可以幫助我們解決這個(gè)安全問題，這個(gè)策略確保我們只能訪問同一站點(diǎn)的資源。
在這種情況下，https://www.evilwebsite.com 嘗試跨站訪問 https://www.bank.com 的資源，同源策略就會(huì)阻止這個(gè)操作，讓釣魚網(wǎng)站無法訪問銀行網(wǎng)站的數(shù)據(jù)。
說了這么多，同源策略和 CORS 又有什么關(guān)系？
2.瀏覽器 CORS
出于安全原因，瀏覽器限制從腳本內(nèi)發(fā)起的跨域 HTTP 請求。例如 XHR 和 Fetch 就遵循同源策略。這意味著使用 API 的 Web 應(yīng)用程序只能從加載應(yīng)用程序的同一個(gè)域請求 HTTP 資源。
日常的業(yè)務(wù)開發(fā)中，我們會(huì)經(jīng)常訪問跨域資源，為了安全的請求跨域資源，瀏覽器使用一種稱為 CORS 的機(jī)制。
CORS 的全名是 Cross-Origin Resource Sharing，即跨域資源共享。盡管默認(rèn)情況下瀏覽器禁止我們訪問跨域資源，但是我們可以利用 CORS 放寬這種限制，在保證安全性的前提下訪問跨域資源。
瀏覽器可以利用 CORS 機(jī)制，放行符合規(guī)范的跨域訪問，阻止不合規(guī)范的跨域訪問。瀏覽器內(nèi)部是怎么做的呢？我們下面就來分析一下。
Web 程序發(fā)出跨域請求后，瀏覽器會(huì)自動(dòng)向我們的 HTTP header 添加一個(gè)額外的請求頭字段：Origin。Origin 標(biāo)記了請求的站點(diǎn)來源：
GET https://api.website.com/users HTTP/1/1
Origin: https://www.mywebsite.com // <- 瀏覽器自己加的
為了使瀏覽器允許訪問跨域資源， 服務(wù)器返回的 response 還需要加一些響應(yīng)頭字段，這些字段將顯式表明此服務(wù)器是否允許這個(gè)跨域請求。
3.服務(wù)端 CORS
作為服務(wù)器開發(fā)人員，我們可以通過在 HTTP 響應(yīng)中添加額外的響應(yīng)頭字段 Access-Control-* 來表明是否允許跨域請求。根據(jù)這些 CORS 響應(yīng)頭字段，瀏覽器可以允許一些被同源策略限制的跨源響應(yīng)。
雖然有好幾個(gè) CORS 響應(yīng)頭字段[3]，但有一個(gè)字段是必加的，那就是 Access-Control-Allow-Origin。這個(gè)頭字段的值指定了哪些站點(diǎn)被允許跨域訪問資源。
1?? 如果我們有服務(wù)器的開發(fā)權(quán)限，我們可以給 https://www.mywebsite.com 加上訪問權(quán)限：將該域添加到 Access-Control-Allow-Origin 中。
這個(gè)響應(yīng)頭字段現(xiàn)在被添加到服務(wù)器發(fā)回給客戶端的 response header 中。這個(gè)字段添加后，如果我們從 https://www.mywebsite.com 發(fā)送跨域請求，同源策略將不再限制 https://api.mywebsite.com 站點(diǎn)返回的資源。
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???收到服務(wù)器返回的 response 后，瀏覽器中的 CORS 機(jī)制會(huì)檢查 Access-Control-Allow-Origin 的值是否等于 request 中 Origin 的值。
在這個(gè)例子中，request 的 Origin 是 https://www.mywebsite.com，這和 response 中 Access-Control-Allow-Origin 的值是一樣的：
3?? 瀏覽器校驗(yàn)通過，前端成功地接收到跨域資源。
那么，當(dāng)我們試圖從一個(gè)沒有在 Access-Control-Allow-Origin 中列出的網(wǎng)站跨域訪問這些資源會(huì)發(fā)生什么呢？
如上圖所示，從 https://www.anotherwebsite.com 跨域訪問 https://api.mywebsite.com 資源，瀏覽器拋出一個(gè) CORS Error，經(jīng)過上面的講解，我們可以讀懂這個(gè)報(bào)錯(cuò)信息了：
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。然而，服務(wù)器在 Access-Control-Allow-Origin 響應(yīng)頭字段中沒有標(biāo)記這個(gè)站點(diǎn)，瀏覽器 CORS 機(jī)制就阻止了這個(gè)響應(yīng)，我們無法在我們的代碼中獲取響應(yīng)數(shù)據(jù)。
“CORS 還允許我們添加通配符
*作為允許的外域，這意味著該資源可以被任意外域訪問，所以要注意這種特殊情況
Access-Control-Allow-Origin 是 CORS 機(jī)制提供的眾多頭字段之一。服務(wù)器開發(fā)人員還可以通過其它頭字段擴(kuò)展服務(wù)器的 CORS 策略，以允許/禁止某些請求。
另一個(gè)常見的響應(yīng)頭字段是 Access-Control-Allow-Methods。其指明了跨域請求所允許使用的 HTTP 方法。
在上圖的案例中，只有GET，POST 或 PUT 方法被允許跨域訪問資源。其他 HTTP 方法，例如 PATCH 和 DELETE 都會(huì)被阻止。
“如果您想知道其它的 CORS 響應(yīng)頭字段是什么以及它們的用途，可以查看此列表[4]。
說到PUT，PATCH 和 DELETE 這幾個(gè) HTTP 方法，CORS 處理這些方法時(shí)還有些不同。這些非簡單請求會(huì)觸發(fā) CORS 的預(yù)檢請求。
4.預(yù)檢請求
CORS 有兩種類型的請求：一種是簡單請求（simple request），一種是預(yù)檢請求（preflight request）。一個(gè)跨域請求到底是簡單的的還是預(yù)檢的，取決于一些 request header。
當(dāng)請求是 GET 或 POST 方法并且沒有任何自定義 Header 字段時(shí)，一般來說就是個(gè)簡單請求。除此之外的任何請求，諸如 PUT，PATCH 或 DELETE 方法，將會(huì)產(chǎn)生預(yù)檢。
“如果你想知道一個(gè)請求必須滿足哪些要求才能成為簡單請求，可以查看 MDN 簡單請求相關(guān)的文檔[5]。
說了這么多，「預(yù)檢請求」到底是什么意思？下面我們就來探討一下。
1???在發(fā)送實(shí)際請求之前，客戶端會(huì)先使用 `OPTIONS`[6] 方法發(fā)起一個(gè)預(yù)檢請求，預(yù)檢請求的 Access-Control-Request-* 中包含有關(guān)我們將要處理的實(shí)際請求的信息：
首部字段 `Access-Control-Request-Method`[7] 告知服務(wù)器，實(shí)際請求要用到的方法是什么 首部字段 `Access-Control-Request-Headers`[8] 告知服務(wù)器，實(shí)際請求將附帶的自定義請求首部字段是什么
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???服務(wù)器接收到預(yù)檢請求后，會(huì)返回一個(gè)沒有 body 的 HTTP 響應(yīng)，這個(gè)響應(yīng)標(biāo)記了服務(wù)器允許的 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?? 瀏覽器收到預(yù)檢響應(yīng)，并檢查是否應(yīng)允許發(fā)送實(shí)際請求。
“??：上圖預(yù)檢響應(yīng)漏了
Access-Control-Allow-Headers: Content-Type
4?? 如果預(yù)檢響應(yīng)檢測通過，瀏覽器會(huì)將實(shí)際請求發(fā)送到服務(wù)器，然后服務(wù)器返回我們需要的資源。
如果預(yù)檢響應(yīng)沒有檢驗(yàn)通過，CORS 會(huì)阻止跨域訪問，實(shí)際的請求永遠(yuǎn)不會(huì)被發(fā)送。預(yù)檢請求是一種很好的方式，可以防止我們訪問或修改那些沒有啟用 CORS 策略的服務(wù)器上的資源。
“? 為了減少網(wǎng)絡(luò)往返次數(shù)，我們可以通過在 CORS 請求中添加 ?
Access-Control-Max-Age頭字段來緩存預(yù)檢響應(yīng)。瀏覽器可以使用緩存來代替發(fā)送新的預(yù)檢請求。
5.認(rèn)證
XHR 或 Fetch 與 CORS 的一個(gè)有趣的特性是，我們可以基于 Cookies[9] 和 HTTP 認(rèn)證信息發(fā)送身份憑證。一般而言，對(duì)于跨域 XHR 或 Fetch 請求，瀏覽器不會(huì)發(fā)送身份憑證信息。
盡管 CORS 默認(rèn)情況下不發(fā)送身份憑證，但我們可以通過添加 Access-Control-Allow-Credentials CORS 響應(yīng)頭來更改它。
如果要在跨域請求中包含 cookie 和其他授權(quán)信息，我們需要做以下操作：
XHR 請求中將 withCredentials字段設(shè)置為trueFetch 請求中將 credentials設(shè)為include服務(wù)器把 Access-Control-Allow-Credentials: true添加到響應(yīng)頭中
//?瀏覽器?fetch?請求
fetch('https://api.mywebsite,com.users',?{
??credentials:?"include"
})
//?瀏覽器?XHR?請求
let?xhr?=?new?XMLHttpRequest();
xhr.withCredentials?=?true;
//?服務(wù)器添加認(rèn)證字段
HTTP/1.1?200?OK
Access-Control-Allow-Credentials:?true
把上面的工作做好后，我們就可以在跨域請求中包含身份憑證信息了。
6.總結(jié)
CORS Error 一定程度上會(huì)讓前端開發(fā)很頭疼，但是遵循它的相關(guān)規(guī)定后，它可以讓我們在瀏覽器中進(jìn)行安全的跨域請求。
同源策略和 CORS 的知識(shí)點(diǎn)有很多，本文只講了一些關(guān)鍵知識(shí)點(diǎn)，如果你想全面學(xué)習(xí) CORS 的相關(guān)知識(shí)，我推薦你查閱MDN 文檔[10]和 W3C 規(guī)范[11]，這些一手知識(shí)是最準(zhǔn)確的。
7.最后
這篇文章就到此結(jié)束了，如果覺得不錯(cuò)的話一定要點(diǎn)贊鼓勵(lì)一下哦，祝大家學(xué)習(xí)進(jìn)步，工作順利！
??愛心三連擊
1.看到這里了就點(diǎn)個(gè)在看支持下吧，你的「在看」是我創(chuàng)作的動(dòng)力。
2.關(guān)注公眾號(hào)
程序員成長指北，回復(fù)「1」加入Node進(jìn)階交流群！「在這里有好多 Node 開發(fā)者，會(huì)討論 Node 知識(shí)，互相學(xué)習(xí)」！3.也可添加微信【ikoala520】，一起成長。
“在看轉(zhuǎn)發(fā)”是最大的支持