通過實例理解Web應用跨域問題
在開發Web應用的過程中，我們經常會遇到所謂“跨域問題(Cross Origin Problem)”。跨域問題是由于瀏覽器的同源策略(Same-origin policy)[1]導致的，它限制了不同源(Origin：域名、協議或端口）之間的資源交互。在這篇文章中，我將通過一些具體的示例來把跨域問題以及主流解決方法說清楚，供大家參考。
1. 什么是跨域問題
跨域問題指的是當一個Web應用程序在訪問另一個域(Origin)的資源時，瀏覽器會阻止這個跨域的請求(Cross Origin Request)。這句針對跨域問題的詮釋里有一個術語“域(Origin)”，它到底是什么呢？
1.1 什么是Origin
在Mozilla官方術語表中，"Origin"指的是一個Web應用/網站的標識，由協議(protocol/scheme)、域名(domain，或主機名host)和端口(port)組成。如果兩個應用/網站的協議、域名和端口都相同，它們就被認為是同源的(same origin)；否則，它們被視為不同源。我們看到：**Origin是一個典型的三元組(protocol, domain, port)**，只有三元組相同的兩個應用/站點才會被認為是同源的(same origin)。
下面是一些判斷兩個應用/站點是否同源的例子及判斷理由：
圖片
知道了Origin三元組后，我們來揪出跨域問題背后的“罪魁禍首”。
1.2 同源策略 - 跨域問題的“罪魁禍首”
瀏覽器為了增加安全性而采取的一項重要措施，那就是“同源策略[2]”。同源策略限制了一個網頁中的腳本只能與同源（三元組：協議、域名、端口相同）的資源進行交互，而不能直接訪問不同源的資源。
瀏覽器的這種同源策略限制主要包含以下幾點:
- Cookie、LocalStorage和IndexDB無法讀取非同源的資源。
- DOM和JS對象無法獲得非同源資源。例如iframe、img等標簽加載的資源，DOM無法訪問；JS無法操作非同源頁面的DOM。
- AJAX請求不能發送到非同源的域名，瀏覽器會阻止非同源的AJAX請求。
- 不能讀取非同源網頁的Cookie、LocalStorage和IndexDB。
下圖(圖片來自網絡)展示了同源策略對惡意腳本代碼對非同源數據訪問的限制：
圖片
上面這張圖片清晰地展示了惡意腳本代碼試圖訪問非同源數據進行惡意登錄的過程。
首先，用戶通過瀏覽器訪問正常網站domain1.com，并用用戶名密碼正常登錄該網站，domain1.com使用cookie技術[3]在用戶瀏覽器中保存了與用戶登錄domain1.com相關的會話信息或token信息。
之后，用戶又訪問了惡意站點domain2.com，該站點首頁的腳本代碼在被下載到用戶瀏覽器中后，試圖訪問瀏覽器cookie中有關domain1.com的cookie信息，并試圖用該信息冒充用戶登錄domain1.com做惡意操作。
瀏覽器的同源策略成功禁止了惡意代碼的這些惡意操作，瀏覽器從domain2.com下載的腳本代碼只能訪問與domain2.com同源的信息。
通過這個過程我們看到：瀏覽器同源策略的本意是防止惡意網站通過腳本竊取用戶的敏感信息，比如登錄憑證、個人資料等。如果同源策略不存在，惡意網站就可以自由地讀取、修改甚至篡改其他網站的數據，給用戶和網站帶來巨大的安全風險。
不過，這種策略的存在給開發人員在開發過程帶來諸多煩惱，比如：跨域數據訪問限制、跨域腳本調用限制以及無法在不同域名之間共享會話信息等。為此，開發人員需要使用一些技術手段來解決這些跨域問題，這增加了開發的復雜性，并且需要額外的配置和處理，給開發人員帶來了一定的麻煩。此外，不正確地處理跨域請求也可能導致安全漏洞，因此開發人員還需要對跨域請求進行合理的安全控制和驗證。
1.3 獲取請求中的“origin”
為了做同源檢測，我們需要獲取和確定請求中的origin信息。那么如何讀取和確定呢？
在HTTP請求頭中，"Origin"字段表示發送請求的頁面或資源的源信息。該字段包含了發送請求的頁面的完整URL或者僅包含協議、域名和端口的部分URL。
在同源策略下，所有的跨域請求都必須攜帶"Origin"請求頭字段，指示請求的來源。因此，在符合同源策略的情況下，每個請求都應該攜帶"Origin"字段。
在服務器端，我們可以通過讀取請求頭中的"Origin"字段來確定請求的origin，具體的方法會根據使用的編程語言和框架而有所不同，例如在Go中可以通過r.Header.Get("Origin")來獲取"Origin"字段的值。由于"Origin"字段是由客戶端提供的，服務器端在處理請求時，需要進行驗證和安全性檢查，以防止偽造或惡意的請求。
然而，有些情況下，請求可能不會攜帶"Origin"字段。例如，非瀏覽器環境下的請求（如服務器間的請求、命令行工具等）可能不會包含"Origin"字段。此外，某些舊版本的瀏覽器可能也不會發送"Origin"字段。
在這種情況下，我們就需要通過其他方式來確定請求的來源。例如，服務端可以查看請求頭中的Referer字段來獲取請求的來源。Referer字段指示了請求的來源頁面的URL。通過檢查Referer字段，服務端可以判斷請求是否來自不同的域。此外，服務器端還可以檢查請求頭中的Host字段，該字段指示了請求的目標主機。如果請求的目標主機與服務端所在的主機不一致，那么可以判斷請求是跨域的。
不過，需要注意的是，服務端的這些方法都依賴于請求頭中的信息，而請求頭可以被客戶端偽造或修改。因此，為了更可靠地判斷請求是否跨域，服務端應該綜合考慮多個因素，并進行適當的驗證和安全措施。
下面我們看一個可以復現跨域問題的示例。
1.4 復現跨域問題的Go代碼示例
出現跨域問題的示例的圖示如下：
圖片
在這個示例中，我們有兩個Web應用：server1.com:8081和server2.com:8082。根據前面對Origin的理解，這兩個Web應用顯然不是同源的。
server1.com和server2.com對應的Go代碼分別如下：
// cross-origin-examples/reproduce/server1.com
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/html; charset=utf-8")
html := `
<!DOCTYPE html>
<html>
<head>
<title>Cross-Origin Example</title>
<script>
function makeCrossOriginRequest() {
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://server2.com:8082/api/data", true);
xhr.onreadystatechange = function() {
if (xhr.readyState === 4 && xhr.status === 200) {
console.log(xhr.responseText);
}
};
xhr.send();
}
</script>
</head>
<body>
<h1>Cross-Origin Example</h1>
<button notallow="makeCrossOriginRequest()">Make Cross-Origin Request</button>
</body>
</html>
`
fmt.Fprintf(w, html)
})
err := http.ListenAndServe("server1.com:8081", nil)
if err != nil {
panic(err)
}
}
// cross-origin-examples/reproduce/server2.com
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
fmt.Printf("recv request: %#v\n", *r)
w.Write([]byte("Welcome to api/data"))
})
http.ListenAndServe("server2.com:8082", nil)
}注：在編譯啟動上面兩個程序之前，需要在/etc/hosts中將server1.com和server2.com的地址指為127.0.0.1。
從示意圖來看，用戶使用瀏覽器與兩個Web應用的交互過程是這樣的：
首先，用戶通過瀏覽器訪問了server1.com:8081的主頁，并收到server1.com:8081返回的應答包體。該應答包體是一個html頁面，如下圖：
圖片
接下來，用戶點擊“Make Cross-Origin Request”按鈕，頁面內通過ajax向server2.com:8082/api/data發起GET請求。
最后，我們在(Edge/Chrome)瀏覽器的控制臺上將看到下面錯誤：
圖片
通過下面server2.com的日志，我們看到ajax請求已經發到server2.com并被正確處理：
recv request: http.Request{Method:"GET", URL:(*url.URL)(0xc00010a480), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{"Accept":[]string{"*/*"}, "Accept-Encoding":[]string{"gzip, deflate"}, "Accept-Language":[]string{"zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6"}, "Connection":[]string{"keep-alive"}, "Origin":[]string{"http://server1.com:8081"}, "Referer":[]string{"http://server1.com:8081/"}, "User-Agent":[]string{"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.81"}}, Body:http.noBody{}, GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"server2.com:8082", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"127.0.0.1:49773", RequestURI:"/api/data", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc000106320)}server2.com在服務端并沒有主動判斷是否是同源請求，但即使服務器沒有進行跨域校驗并返回成功的響應和數據，瀏覽器也會攔截腳本讀取跨域響應數據的嘗試，這是由瀏覽器的同源策略所決定的。這也是我們看到上面截圖中報錯的原因。
那么解決跨域問題有哪些主流的解決方法呢？我們繼續看一下。
2. 跨域問題的主流解決方法
為了解決跨域問題，有下面幾種常見的解決方法：
- JSONP（JSON with Padding）
通過動態創建<script>標簽來加載跨域的JavaScript腳本，進而實現跨域數據獲取。
- CORS[4]（跨域資源共享, CORS是Cross-Origin Resource Sharing）
通過在服務器響應頭中設置CORS訪問策略以允許指定的Origin訪問資源。
- 代理服務器
在同域下創建一個代理服務器，將跨域請求轉發到目標服務器并返回結果。代理服務器對響應頭統一增加Access-Control-Allow-Origin等CORS相關字段，表示允許跨域訪問。
其中CORS是解決跨域問題時應用最為廣泛的方法。CORS(跨域資源共享)主要是通過設置HTTP頭來解決跨域問題的。
服務器端通過在響應(Response)的HTTP頭中設置Access-Control-Allow-Origin頭來設置允許的請求來源域(Origin: 三元組)。
如果設置為“*”，則表示允許任意域發起跨域請求：
Access-Control-Allow-Origin: *也可以在響應中將Access-Control-Allow-Origin設置為只允許指定的Origin訪問資源，比如：
Access-Control-Allow-Origin: http://server1.com:8081Access-Control-Allow-Origin頭的值還支持設置多個origin，多個origin用逗號分隔：
Access-Control-Allow-Origin: http://server1.com:8081,https://server2.com:8082注：關于Access-Control-Allow-Origin的值是否要帶上protocol和port的問題，我實測的情況是必須帶。前面說過：Origin是三元組，只有完全相同才算是同源。
此外，域名必須具體到二級域名才能匹配成功。頂級域名如“.com”、“.org”是不允許的。
服務端響應的跨域設置還不僅Access-Control-Allow-Origin一個，我們還可以設置Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Max-Age等字段來更細粒度的進行跨域訪問控制。
注：有些值Access-Control-XXX-xxx字段僅用于Preflight Request(預檢請求)[5]，比如：Access-Control-Allow-Methods。CORS Preflight Request是一種CORS請求，它使用特定的方法和Header檢查CORS協議是否被理解和服務器是否被感知。它是一個OPTIONS請求，使用兩個或三個HTTP請求頭： Access-Control-Request-Method（訪問控制請求方法）、Origin（起源）和可選的 Access-Control-Request-Headers（訪問控制請求頭）。
3. 使用CORS解決跨域問題的示例
下面我們修改一下server2.com的代碼來解決前面遇到的跨域問題：
// cross-origin-examples/solve/server2.com/main.go
func main() {
http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
fmt.Printf("recv request: %#v\n", *r)
w.Header().Set("Access-Control-Allow-Origin", "http://server1.com:8081")
w.Write([]byte("Welcome to api/data"))
})
http.ListenAndServe("server2.com:8082", nil)
}我們僅在server2.com/main.go中增加了一行代碼，旨在允許來自http://server1.com:8081的跨域請求訪問server2.com的資源：
w.Header().Set("Access-Control-Allow-Origin", "http://server1.com:8081")啟動新版server2.com后，再點擊頁面上的“Make Cross-Origin Request”按鈕，我們在瀏覽器的控制臺上就能看到應答成功被接受并顯示。
4. 小結
本文介紹了日常Web應用開發過程中經常遇到的跨域問題，探討了“域(Origin)”概念以及跨域問題的真實原因：即瀏覽器的同源策略限制了不同源請求資源的訪問。
接下來通過Go代碼示例演示了跨域問題的表現形式，并介紹了幾種主要的跨域解決方案，最后對最常見的CORS解決方案做了細致說明，并用實例展示了服務端設置CORS頭后跨域問題的解決。
希望本文可以幫助大家更深入的理解和掌握Web應用跨域問題以及解決方法。
本文涉及的源碼可以在這里[6]下載。
5. 參考資料
- The ultimate guide to enabling Cross-Origin Resource Sharing (CORS)[7] - https://blog.logrocket.com/the-ultimate-guide-to-enabling-cross-origin-resource-sharing-cors/
- Cross-Origin Resource Sharing (CORS)[8] - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- Glossary: Origin[9] - https://developer.mozilla.org/en-US/docs/Glossary/Origin
- Same-origin policy[10] - https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
