什麼是跨域，後端工程師如何處理跨域

• 什麼是跨域
  • 前言
  • 什麼是跨域
  • 同源策略
    • 什麼是同源策略
    • 非同源的限制條件
    • 同源策略的目的
  • 如何處理跨域
  • 處理 AJAX 非同源的限制
    • CORS
    • 簡單請求（simple request）
      • 簡單請求基本流程
      • withCredentials 屬性
    • 非簡單請求（not-so-simple request）
      • 預檢資訊
      • 預檢資訊的請求
      • 預檢資訊的響應
      • 正常資訊的響應和返回
    • 服務端程式碼如何處理
  • 如何除錯跨域
  • 參考

什麼是跨域

前言

作為一名後端開發工程師，在給前端同事寫介面的時候，經常碰到他們講，你的介面跨域了，那麼什麼是跨域，這裡來研究下。

什麼是跨域

先來看下跨域的定義

跨域的廣義定義：跨域是指一個域下的文件或指令碼試圖去請求另一個域下的資源。

我們經常遇到的跨域是由瀏覽器同源策略限制的一類請求場景。

慄如，下面的請求就發生了跨域，在京東的 H5 頁面中請求淘寶的介面

上面栗子中跨域最終的罪魁禍首就是瀏覽器的同源策略。

1、因為上面的域名不相同，所以請求的介面被認為是非同源。

2、同時出於安全性，瀏覽器限制指令碼內發起的跨源 HTTP 請求。 例如，XMLHttpRequest 和 Fetch API 遵循同源策略。所以上面的請求就報了跨域的錯誤。

同源策略

什麼是同源策略

同源策略/SOP （Same origin policy）是一種約定，由 Netscape 公司1995年引入瀏覽器。

同源策略是指在 Web 瀏覽器中，允許某個網站指令碼訪問另一個網站的資料，但前提是這兩個網站必須滿足三個相同:

1、協議相同；

2、域名相同；

3、埠相同；

一旦兩個網站滿足上述條件，這兩個網站就被認定為具有相同來源。

非同源的限制條件

如果兩個網站非同源，將受到下面的幾種限制

1、Cookie、LocalStorage 和 IndexDB 無法讀取；

2、DOM 無法獲得；

3、AJAX 請求不能傳送。

同源策略的目的

同源政策的目的，是為了保證使用者資訊的安全，防止惡意的網站竊取資料。

慄如：Cookie 中存了一些使用者的登陸資訊，如果沒有同源策略的限制，那麼任何網站都能訪問 Cookie，使用者的資訊就會洩露了，就能偽造使用者資訊登陸目標網站了，這顯然是有很大的安全隱患的。

如何處理跨域

因為非同源有上面三種限制，這種能夠規避一定的安全問題，但是有時候我們正常的使用也受到了影響，所以有時候我們需要想辦法規避這種限制。

非同源限制中的

1、Cookie、LocalStorage 和 IndexDB 無法讀取；

2、DOM 無法獲得；

這裡就不展開討論了，這種只需要在前端頁面中進行調整就行了，這裡重點關注下有和後端互動的 3、AJAX 請求不能傳送 的這種限制。

處理 AJAX 非同源的限制

同源政策規定，AJAX 請求只能發給同源的網址，否則就報錯。

除了架設伺服器代理（瀏覽器請求同源伺服器，再由後者請求外部服務），有三種方法規避這個限制。

1、JSONP

2、WebSocket

3、CORS

關於 WebSocket 和 JSONP 的處理參見瀏覽器同源政策及其規避方法

作為服務端開發，對於 CORS 使用的比較多，這裡展開討論下

CORS

CORS 是一個 W3C 標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。

它允許瀏覽器向跨源伺服器，發出 XMLHttpRequest 請求，從而克服了 AJAX 只能同源使用的限制。

跨源資源共享 (CORS)（或通俗地譯為跨域資源共享）是一種基於 HTTP 頭的機制，該機制通過允許伺服器標示除了它自己以外的其它 origin（域，協議和埠），使得瀏覽器允許這些 origin 訪問載入自己的資源。跨源資源共享還通過一種機制來檢查伺服器是否會允許要傳送的真實請求，該機制通過瀏覽器發起一個到伺服器託管的跨源資源的"預檢"請求。在預檢中，瀏覽器傳送的頭中標示有 HTTP 方法和真實請求中會用到的頭。

實現CORS通訊的關鍵是伺服器。只要伺服器實現了CORS介面，就可以跨源通訊。

CORS 的使用的關鍵在服務端，瀏覽器傳送請求，服務端接收到客戶端請求做一些判斷（請求方是否在自己的“白名單”裡？），如果沒問題就返回資料，否則拒絕。

瀏覽器將 CORS 請求分成兩類：

簡單請求（simple request）

非簡單請求（not-so-simple request）

簡單請求（simple request）

某些請求不會觸發 CORS 預檢請求。這樣的請求為“簡單請求”，只要同時滿足下面的兩大條件就是簡單請求。

1、請求方法是以下三種方法之一

• HEAD

• GET

• POST

2、HTTP的頭資訊不超出以下幾種欄位：

• Accept

• Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type：只限於三個值 application/x-www-form-urlencoded、multipart/form-data、text/plain

簡單請求基本流程

簡單請求沒有預檢的流程，所以瀏覽器只會傳送一次請求，發出的 CORS 請求，頭資訊中會有一個 Origin 欄位。

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

Origin 欄位用來說明，本次請求來自哪個源（協議 + 域名 + 埠）。伺服器根據這個值，決定是否同意這次請求。

如果 Origin 指定的源，不在許可範圍內，伺服器會返回一個正常的 HTTP 回應。瀏覽器發現，這個回應的頭資訊沒有包含 Access-Control-Allow-Origin 欄位（詳見下文），就知道出錯了，從而丟擲一個錯誤，被 XMLHttpRequest 的 onerror 回撥函式捕獲。注意，這種錯誤無法通過狀態碼識別，因為 HTTP 回應的狀態碼有可能是 200。

如果 Origin 指定的域名在許可範圍內，伺服器返回的響應，會多出幾個頭資訊欄位。

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

上面以 Access-Control- 開頭的都是和 CORS 請求相關的欄位。

Access-Control-Allow-Origin

該欄位是必須的。它的值要麼是請求時Origin欄位的值，要麼是一個*，表示接受任意域名的請求。

Access-Control-Allow-Credentials

該欄位可選。它的值是一個布林值，表示是否允許傳送 Cookie。預設情況下，Cookie 不包括在 CORS 請求之中。設為 true，即表示伺服器明確許可，Cookie 可以包含在請求中，一起發給伺服器。這個值也只能設為 true，如果伺服器不要瀏覽器傳送 Cookie，刪除該欄位即可。

Access-Control-Expose-Headers

該欄位可選。CORS 請求時，XMLHttpRequest 物件的 getResponseHeader() 方法只能拿到6個基本欄位：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他欄位，就必須在 Access-Control-Expose-Headers 裡面指定。上面的例子指定，getResponseHeader('FooBar') 可以返回 FooBar 欄位的值。

withCredentials 屬性

CORS請求預設不傳送 Cookie 和 HTTP 認證資訊。如果要把 Cookie 發到伺服器，一方面要伺服器同意，指定 Access-Control-Allow-Credentials 欄位。

Access-Control-Allow-Credentials: true

另一方面，開發者必須在AJAX請求中開啟 withCredentials 屬性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否則，即使伺服器同意傳送 Cookie，瀏覽器也不會傳送。或者，伺服器要求設定 Cookie，瀏覽器也不會處理。

但是，如果省略 withCredentials 設定，有的瀏覽器還是會一起傳送 Cookie。這時，可以顯式關閉 withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要傳送 Cookie，Access-Control-Allow-Origin 就不能設為星號，必須指定明確的、與請求網頁一致的域名。同時，Cookie 依然遵循同源政策，只有用伺服器域名設定的 Cookie 才會上傳，其他域名的 Cookie 並不會上傳，且（跨源）原網頁程式碼中的 document.cookie 也無法讀取伺服器域名下的 Cookie。

非簡單請求（not-so-simple request）

不同時滿足上面簡單請求的兩大條件的就是非簡單請求

比如請求方法是 PUT 或 DELETE，或者 Content-Type 欄位的型別是 application/json。

非簡單請求的 CORS 請求，會在正式通訊之前，增加一次 HTTP 查詢請求，稱為"預檢"請求（preflight）。

瀏覽器先詢問伺服器，當前網頁所在的域名是否在伺服器的許可名單之中，以及可以使用哪些 HTTP 動詞和頭資訊欄位。只有得到肯定答覆，瀏覽器才會發出正式的 XMLHttpRequest 請求，否則就報錯。

使用下面的指令碼來請求追書的 H5 頁面 https://www.zhuishushenqi.com

var url = 'https://api.zhuishushenqi.com/captcha/register?type=geetest';
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.setRequestHeader('x-device-id', 'test');
xhr.send();

可以看到傳送了兩次請求的資訊，一次的型別是 preflight 也就是預檢請求

預檢資訊

預檢資訊的請求

"預檢"請求用的請求方法是 OPTIONS，表示這個請求是用來詢問的。頭資訊裡面，關鍵欄位是 Origin，表示請求來自哪個源。

OPTIONS /captcha/register?type=geetest HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Access-Control-Request-Headers: x-device-id
Access-Control-Request-Method: GET
Connection: keep-alive
Host: api.zhuishushenqi.com
Origin: https://www.zhuishushenqi.com
Referer: https://www.zhuishushenqi.com/

除了 Origin 欄位，"預檢"請求的頭資訊包括兩個特殊欄位。

1、Access-Control-Request-Method

該欄位是必須的，用來列出瀏覽器的 CORS 請求會用到哪些 HTTP 方法，上例是 GET。

2、Access-Control-Request-Headers

該欄位是一個逗號分隔的字串，指定瀏覽器 CORS 請求會額外傳送的頭資訊欄位，上例是 x-device-id。

預檢資訊的響應

來看下正常的響應，使用上面的指令碼在淘寶的 H5 頁面進行訪問

伺服器收到"預檢"請求以後，檢查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers欄位以後，確認允許跨源請求，就可以做出回應。

HTTP/1.1 200 OK
Allow: GET,HEAD
Content-Type: text/html; charset=utf-8
Accept-Ranges: bytes
Access-Control-Allow-Origin: https://www.zhuishushenqi.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Headers: Content-Type,x-app-name,x-device-id

上面的 HTTP 回應中，關鍵的是 Access-Control-Allow-Origin 欄位，表示 https://www.zhuishushenqi.com 可以請求資料，不會產生跨域的錯誤。該欄位也可以設為 * 號，表示同意任意跨源請求。

Access-Control-Allow-Origin: *

如果伺服器否定了"預檢"請求，會返回一個正常的 HTTP 回應，但是沒有關鍵資訊 Access-Control-Allow-Origin 的頭資訊欄位。這時，瀏覽器就會認定，伺服器不同意預檢請求，因此觸發一個錯誤，被 XMLHttpRequest 物件的 onerror 回撥函式捕獲。控制檯就會列印跨域的報錯資訊，例如，文中示例 1 中的跨域報錯。

Access to XMLHttpRequest at 'https://h5api.m.taobao.com/h5/mtop.user.getusersimple/1.0' from origin 'https://www.jd.com' has been blocked by CORS policy: 
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

分析下正常返回的幾個屬性

1、Access-Control-Allow-Methods

它的值是逗號分隔的一個字串，表明伺服器支援的所有跨域請求的方法。注意，返回的是所有支援的方法，而不單是瀏覽器請求的那個方法。這是為了避免多次"預檢"請求。

2、Access-Control-Allow-Headers

如果瀏覽器請求包括 Access-Control-Request-Headers 欄位，則 Access-Control-Allow-Headers 欄位是必需的。它也是一個逗號分隔的字串，表明伺服器支援的所有頭資訊欄位，不限於瀏覽器在"預檢"中請求的欄位。

3、Access-Control-Allow-Credentials

該欄位與簡單請求時的含義相同。

4、Access-Control-Max-Age

該欄位可選，用來指定本次預檢請求的有效期，單位為秒。上面結果中，有效期是1天（86400秒），即允許快取該條回應86400秒（即1天），在此期間，不用發出另一條預檢請求。

正常資訊的響應和返回

一旦伺服器通過了"預檢"請求，以後每次瀏覽器正常的 CORS 請求，就都跟簡單請求一樣，會有一個 Origin 頭資訊欄位。伺服器的回應，也都會有一個 Access-Control-Allow-Origin 頭資訊欄位。

下面是"預檢"請求之後，瀏覽器的正常CORS請求。

GET /captcha/register?type=geetest HTTP/1.1
Accept: */*
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: keep-alive
Host: api.zhuishushenqi.com
Origin: https://www.zhuishushenqi.com
Referer: https://www.zhuishushenqi.com/
x-device-id: test

上面頭資訊的Origin欄位是瀏覽器自動新增的。

下面是伺服器正常的回應。

HTTP/1.1 200 OK
Cache-Control: no-store
Content-Length: 129
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: https://www.zhuishushenqi.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Headers: Content-Type,x-app-name,x-device-id

服務端程式碼如何處理

這裡使用的是 GO 中的 gin 框架，來看下後端對 CORS 跨源通訊的處理

var origins = map[string]bool{
	"http://test.hello.com": true,
	"https://test.hello.com": true,
}

func Cross() gin.HandlerFunc {
	return func(c *gin.Context) {
		origin := c.Request.Header.Get("Origin")
		if origins[origin] {
			c.Writer.Header().Set("Access-Control-Allow-Origin", origin)
			c.Writer.Header().Set("Access-Control-Allow-Credentials", "true")
			c.Writer.Header().Set("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS, TRACE")
			c.Writer.Header().Set("Access-Control-Allow-Headers", "Authorization, Content-Type")
		}
		if c.Request.Method == "OPTIONS" {
			c.AbortWithStatus(200)
			return
		}
		c.Next()
	}
}

如何除錯跨域

瞭解完什麼是跨域之後，來學習下如何快速方便的除錯跨域

目前瀏覽器在使用 ajax 技術上都是使用 XMLHttpRequest(XHR) 物件來對伺服器進行互動。

所以使用 XMLHttpRequest 就能除錯跨域請求

var url = 'https://h5api.m.taobao.com/h5/mtop.user.getusersimple/1.0';
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

在需要處理跨域的 H5 頁面的的 Console 中執行上面的指令碼即可，如果有跨域就會報錯。例如文中圖一的示例。

參考

【跨域資源共享 CORS 詳解】https://www.ruanyifeng.com/blog/2016/04/cors.html
【前端常見跨域解決方案】https://segmentfault.com/a/1190000011145364
【瀏覽器同源政策及其規避方法】https://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
【Same-origin_policy】https://en.wikipedia.org/wiki/Same-origin_policy
【CORS】https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORS
【什麼是跨域，後端工程師如何處理跨域】https://boilingfrog.github.io/2022/05/03/什麼是跨域/