CORS跨域與Nginx反向代理跨域優劣對比

木子墨發表於2019-01-19
CORS跨域Nginx

最近寫了一些關於前後端分離專案之後，跨域相關方案的基本原理和常見誤區的帖子，主要包括CORS和Nginx反向代理。這兩種方案專案中都有在用，各有優缺，關於具體使用哪種方案，大家的觀點也不大一致，本文主要就此展開一下，從前後端及伺服器配置、安全性、移植靈活性、擴充套件性等方面詳細對比一下兩種方案的優缺，以便於後期在方案選型上對大家有所幫助。

前端配置

CORS方案：跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要設定一下xmlhttprequest的withCrendetails屬性，使用vue-resouce時設定如下

Vue.http.options.credentials = true

用axios時，可以在攔截器中設定如下

axios.interceptors.request.use((config) => {
    config.withCredentials = true
    return config
}, (error) => {
    return Promise.reject(error)
})

使用原生XMLHttpRequest物件時如下，

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

如果不需要傳遞cookie，最好置成false，避免不嗯瀏覽器預設允許cookie的攜帶。
Nginx反向代理：此時前端相當於不跨域，和正常請求一致，無需額外配置。

後端配置

CORS方案： 後端需要包裝ACA系列header，

`Access-Control-Allow-Origin` `*`;
`Access-Control-Allow-Credentials` "true"; 
`Access-Control-Allow-Headers` `X-Requested-With`;

除此以外無需額外配置。
Nginx反向代理：此時後端相當於不跨域，和正常請求一致，無需額外配置。

伺服器配置

CORS方案： 無。
Nginx反向代理：該方案跨域工作都集中在nginx伺服器上，配置如下

...
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
location /api {
   proxy_pass https://b.test.com; # 設定代理伺服器的協議和地址
   proxy_cookie_domain b.test.com  a.test.com; # 修改cookie，針對request和response互相寫入cookie
}       
...

原理移步nginx反向代理跨域基本配置與常見誤區、nginx配置解析之客戶端真實IP的傳遞

安全性

CORS方案： 由於此時瀏覽器會預設新增origin屬性，服務端可以直接查到請求來源，便於控制來源、遮蔽黑名單連結。同時服務端域名和埠會暴露出來。
Nginx反向代理：反向代理方案中沒有預設的origin頭部可以使用，但是可以通過X-Forward-For頭部檢視客戶端及各級代理ip，也可以實現一定程度的回溯追蹤和黑名單遮蔽。由於反向代理中，可以採用內網地址訪問介面伺服器，這樣可以一定程度上保護介面伺服器不暴露出來。

移植靈活性、擴充套件性

CORS方案： 只需要在程式碼或者配置中心進行黑白名單配置即可，方便移植和擴充套件。
Nginx反向代理：不同環境服務域名可能不一致，因此nginx配置也各不相同，不便於移植。而對於擴充套件性，當存在新的專案需要訪問介面伺服器時，需要首先訪問nginx中server指定的域名，再由server域名反向代理到介面伺服器，比如

server { 
    listen       8443;
    server_name  a.test.com;    
    client_max_body_size            100m;
        
    ssl ...

    location /micro{
        proxy_pass   https://b.test.com;  #反向代理
        proxy_cookie_domain b.test.com a.test.com; #修改cookie
        add_header `Access-Control-Allow-Origin` `htps://c.test.com`;
        add_header `Access-Control-Allow-Credentials` "true"; 
        add_header Access-Control-Allow-Headers X-Requested-With;
    }
}

這個時候跨域模型就變了，由單純的a.test.com反向代理到b.test.com，變成了a.test.com反向代理到b.test.com以及c.test.comCORS到a.test.com再反向代理到b.test.comd的情況。這個有點繞，但仔細想一下就會明白。這無疑增加了後期的維護成本。

綜合對比

綜合以上，我們大致可以得到如下圖示

Item CORS Nginx反向代理
程式碼配置–前端 credentials=true 無
程式碼配置–後臺 setHeader:ACA-Origin、ACA-Method、ACA-Credentials等 無
伺服器配置 無 Nginx配置
移植靈活性 高、無需額外配置 低、每套環境配置可能均不相同
安全性 來源可控、直接追溯 X-Forwarded-For追溯多級來源
新專案擴充套件 黑白名單控制 更新配置，跨域模型會產生變化

對比結論

綜上呢，對於公共基礎服務，由於涉及到對接的前端專案可能比較多，開發測試部署環境也比較多，整體上來講我更傾向於推薦大家使用CORS方案。而對於一些對立性強的小專案，使用nginx則可以降低你的開發成本，快速發開快速上線。具體使用當然也要結合工作實際，按需使用吧。
此外對於Nginx反向代理方案使用時，推薦使用內部域名/ip作為介面伺服器的入口，儘量不要暴露到外面，以免出現不必要的安全問題。

～本篇完～歡迎大家一起討論～

相關文章