跨域問題是怎樣造成的？

跨域問題的由來

相信很多人都或多或少了解過跨域問題，尤其在現如今前後端分離大行其道的時候。

你在本地開發一個前端專案，這個專案是透過 node 執行的，埠是9528，而服務端是透過 spring boot 提供的，埠號是7001。

當你呼叫一個服務端介面時，很可能得到類似下面這樣的一個錯誤：

然後你在傳送請求的地方debug，在出現異常的地方你將得到這樣的結果：

異常物件很詭異，返回的 response 是 undefined 的，並且 message 訊息中只有一個“Network Error”。

看到這裡你應該要知道，你遇到跨域問題了。

但是你需要明確的一點是，這個請求已經發出去了，服務端也接收到並處理了，但是返回的響應結果不是瀏覽器想要的結果，所以瀏覽器將這個響應的結果給攔截了，這就是為什麼你看到的response是undefined。

瀏覽器的同源策略

那瀏覽器為什麼會將服務端返回的結果攔截掉呢？

這就需要我們瞭解瀏覽器基於安全方面的考慮，而引入的 同源策略（same-origin policy） 了。

早在1995年，Netscape 公司就在瀏覽器中引入了“同源策略”。

最初的 “同源策略”，主要是限制Cookie的訪問，A網頁設定的 Cookie，B網頁無法訪問，除非B網頁和A網頁是“同源”的。

那麼怎麼確定兩個網頁是不是“同源”呢，所謂“同源”就是指“協議+域名+埠”三者相同，即便兩個不同的域名指向同一個ip地址，也非同源。

沒有同源策略的保護

那麼為什麼要做這個同源的限制呢？因為如果沒有同源策略的保護，瀏覽器將沒有任何安全可言。

老李是一個釣魚愛好者，經常在

我要買(51mai.com)

的網站上買各種釣魚的工具，並且透過

銀行(yinhang.com)

以賬號密碼的方式直接支付。

這天老李又在

51mai.com

上買了一根魚竿，輸入銀行賬號密碼支付成功後，在支付成功頁看到一個叫

釣魚(diaoyu.com)

的網站投放的一個“免費領取魚餌”的廣告。

老李什麼都沒想就點選了這個廣告，跳轉到了釣魚的網站，殊不知這真是一個 “釣魚” 網站，老李銀行賬戶裡面錢全部被轉走了。

以上就是老李的錢被盜走的過程：

1。老李購買魚竿，並登入了銀行的網站輸入賬號密碼進行了支付，瀏覽器在本地快取了銀行的Cookie

2。老李點選釣魚網站，釣魚網站使用老李登入銀行之後的Cookie，偽造成自己是老李進行了轉賬操作。

這個過程就是著名的CSRF（Cross Site Request Forgery），跨站請求偽造，正是由於可能存在的偽造請求，導致了瀏覽器的不安全。

那麼如何防止CSRF攻擊呢，可以參考這篇文章：如何防止CSRF攻擊？

同源策略限制哪些行為

上面說了 **同源策略 **是一個安全機制，他本質是限制了從一個源載入的文件或指令碼如何與來自另一個源的資源進行互動，這是一個用於隔離潛在惡意檔案的重要安全機制。

隨著網際網路的發展，“同源策略”越來越嚴格，不僅限於Cookie的讀取。目前，如果非同源，共有三種行為受到限制。

（1） Cookie、LocalStorage 和 IndexDB 無法讀取。

（2） DOM 無法獲得。

（3） 請求的響應被攔截。

雖然這些限制是必要的，但是有時很不方便，合理的用途也會受到影響，所以為了能夠獲取非“同源”的資源，就有了跨域資源共享。

跨域資源共享

看到這裡你應該明白，為什麼文章開頭的請求會被攔截了，原因就是請求的源和服務端的源不是“同源”，而服務端又沒有設定允許的跨域資源共享，所以請求的響應被瀏覽器給攔截掉了。

CORS 是一個 W3C 標準，全稱是“跨域資源共享”（Cross Origin Resource Sharing），它允許瀏覽器向跨源伺服器，發出 XMLHttpRequest 請求，從而克服了只能傳送同源請求的限制。

CORS實現機制

那跨域資源共享機制是怎樣實現的呢？

當一個資源（origin）透過指令碼向另一個資源（host）發起請求，而被請求的資源（host）和請求源（origin）是不同的源時（協議、域名、埠不全部相同），瀏覽器就會發起一個

跨域 HTTP 請求

，並且瀏覽器會自動將當前資源的域新增在請求頭中一個叫 Origin 的 Header 中。

當然了，有三個標籤本身就是允許跨域載入資源的：