器代理實(shí)戰(zhàn))
1. 同源策略前端世界的“安全門衛(wèi)”做前端開發(fā)只要和瀏覽器打交道就繞不開“同源策略”這四個(gè)字。它就像瀏覽器內(nèi)置的一位鐵面無(wú)私的門衛(wèi)時(shí)刻審視著每一個(gè)進(jìn)出頁(yè)面的請(qǐng)求決定是放行還是攔截。簡(jiǎn)單來(lái)說(shuō)同源策略是一種核心的安全機(jī)制它規(guī)定了一個(gè)源Origin加載的文檔或腳本如何與另一個(gè)源的資源進(jìn)行交互。它的存在從根本上防止了惡意網(wǎng)站竊取用戶在其他網(wǎng)站比如你的銀行或郵箱的敏感數(shù)據(jù)。對(duì)于前端開發(fā)者而言理解這位“門衛(wèi)”的規(guī)則并學(xué)會(huì)在合規(guī)的前提下與“鄰居”其他源安全通信是一項(xiàng)必備技能。那么什么是“同源”判斷標(biāo)準(zhǔn)非常嚴(yán)格必須同時(shí)滿足三個(gè)要素完全相同協(xié)議、域名、端口。只要有一個(gè)不同就被視為“跨源”或我們常說(shuō)的“跨域”。舉個(gè)例子https://www.example.com:443這個(gè)源它與以下地址的關(guān)系是https://www.example.com:8080-不同源端口不同http://www.example.com:443-不同源協(xié)議不同https://api.example.com:443-不同源域名不同子域名也算不同源https://www.example.com:443/path/to/page-同源僅路徑不同不影響同源判斷這位“門衛(wèi)”主要限制以下幾種行為1) 無(wú)法讀取非同源網(wǎng)頁(yè)的 Cookie、LocalStorage 和 IndexedDB2) 無(wú)法獲取非同源網(wǎng)頁(yè)的 DOM 元素典型的如iframe嵌套不同源頁(yè)面3) 限制通過(guò)XMLHttpRequest或Fetch API發(fā)起的跨源 HTTP 請(qǐng)求。最后一點(diǎn)正是我們?nèi)粘ｉ_發(fā)中遇到“跨域問(wèn)題”最常見的場(chǎng)景。當(dāng)你從localhost:3000的前端項(xiàng)目去請(qǐng)求localhost:8080的后端 API 時(shí)瀏覽器控制臺(tái)那個(gè)經(jīng)典的CORS policy錯(cuò)誤就出現(xiàn)了。理解它不是為了對(duì)抗它而是為了在它的規(guī)則下安全、優(yōu)雅地實(shí)現(xiàn)業(yè)務(wù)需求。1.1 為什么需要同源策略一個(gè)生動(dòng)的比喻為了更直觀地理解我們可以把互聯(lián)網(wǎng)想象成一個(gè)巨大的社區(qū)每個(gè)網(wǎng)站源就是社區(qū)里的一棟房子。你的房子https://your-bank.com里有你的保險(xiǎn)柜Cookie、登錄態(tài)、私人文件DOM和電話AJAX請(qǐng)求。如果沒有同源策略這個(gè)社區(qū)保安會(huì)發(fā)生什么一個(gè)偽裝成送快遞的惡意網(wǎng)站http://evil-site.com可以輕易地打開你家的窗戶通過(guò)腳本偷看你的保險(xiǎn)柜密碼翻閱你的私人文件甚至用你的電話冒充你給銀行打電話轉(zhuǎn)賬。這無(wú)疑是災(zāi)難性的。同源策略的作用就是給每棟房子裝上安全鎖和監(jiān)控。它規(guī)定只有從你自己房子內(nèi)部發(fā)出的指令才能操作你自己房子的東西。來(lái)自其他房子的快遞員腳本只能按門鈴發(fā)起請(qǐng)求但未經(jīng)你明確許可CORS機(jī)制絕對(duì)不能進(jìn)門更不能亂動(dòng)你的物品。這樣即使你不小心訪問(wèn)了惡意網(wǎng)站它也無(wú)法直接竊取你在其他重要網(wǎng)站如銀行、郵箱的會(huì)話信息極大地保護(hù)了用戶的數(shù)據(jù)安全和隱私。作為開發(fā)者我們的任務(wù)不是拆掉這把鎖而是學(xué)會(huì)如何正確地使用“訪客登記系統(tǒng)”讓合法的、我們需要的“訪客”如后端API、第三方服務(wù)能夠安全地進(jìn)來(lái)。1.2 跨域請(qǐng)求的典型場(chǎng)景與錯(cuò)誤在實(shí)際開發(fā)中跨域請(qǐng)求無(wú)處不在尤其是在前后端分離的架構(gòu)下。以下是一些典型場(chǎng)景本地開發(fā)前端運(yùn)行在http://localhost:3000后端 API 服務(wù)運(yùn)行在http://localhost:8080。多環(huán)境部署Web 應(yīng)用部署在https://www.myapp.com而靜態(tài)資源圖片、字體或 API 服務(wù)器部署在獨(dú)立的域名https://cdn.myapp.com或https://api.myapp.com。第三方服務(wù)集成你的網(wǎng)站需要調(diào)用地圖 API如高德、百度、支付接口如支付寶、微信支付、社交登錄如微信、微博 OAuth等這些服務(wù)的域名與你自己的站點(diǎn)域名必然不同。當(dāng)瀏覽器攔截了一個(gè)跨域請(qǐng)求時(shí)你會(huì)在開發(fā)者工具的 Console 或 Network 面板中看到明確的錯(cuò)誤信息。最常見的就是 CORS 相關(guān)錯(cuò)誤例如Access to fetch at ‘https://api.example.com/data‘ from origin ‘https://www.myapp.com‘ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin‘ header is present on the requested resource.或者更詳細(xì)的預(yù)檢請(qǐng)求錯(cuò)誤Access to fetch at ... has been blocked by CORS policy: Response to preflight request doesn‘t pass access control check: It does not have HTTP ok status.這些紅色的錯(cuò)誤日志正是同源策略這位“門衛(wèi)”在盡職盡責(zé)地提醒你當(dāng)前請(qǐng)求未獲得目標(biāo)服務(wù)器的明確許可。解決這些錯(cuò)誤就是我們接下來(lái)要探討的核心。2. 經(jīng)典跨域解決方案深度剖析面對(duì)跨域限制前端社區(qū)發(fā)展出了多種解決方案。每種方案都有其特定的適用場(chǎng)景、實(shí)現(xiàn)原理和優(yōu)缺點(diǎn)。我們不能只會(huì)調(diào)用axios或fetch更要理解背后發(fā)生了什么。這里我們深入剖析幾種最經(jīng)典、最常用的方案。2.1 JSONP基于script標(biāo)簽的“歷史智慧”JSONPJSON with Padding是一種非常古老但一度非常流行的跨域技術(shù)。它巧妙地利用了 HTML 中script標(biāo)簽的一個(gè)特性其src屬性可以跨域加載 JavaScript 文件。瀏覽器不會(huì)對(duì)script標(biāo)簽的跨域加載施加同源策略限制。實(shí)現(xiàn)原理前端不直接發(fā)起 AJAX 請(qǐng)求而是動(dòng)態(tài)創(chuàng)建一個(gè)script標(biāo)簽。將這個(gè)script標(biāo)簽的src屬性設(shè)置為目標(biāo) API 的 URL并在 URL 上通過(guò)查詢參數(shù)通常是callback指定一個(gè)全局回調(diào)函數(shù)名例如https://api.example.com/data?callbackhandleResponse。將這個(gè)script標(biāo)簽插入到 DOM 中瀏覽器就會(huì)去請(qǐng)求這個(gè) URL。服務(wù)器端需要配合這個(gè)約定。它接收到請(qǐng)求后不是返回標(biāo)準(zhǔn)的 JSON而是返回一段JavaScript 代碼這段代碼的內(nèi)容是調(diào)用前端指定的那個(gè)回調(diào)函數(shù)并將真正的數(shù)據(jù)作為參數(shù)傳入。例如返回handleResponse({status: ok, data: {...}})。瀏覽器加載并執(zhí)行這段返回的 JS 代碼自然就調(diào)用了前端的handleResponse函數(shù)數(shù)據(jù)就這樣“跨域”傳遞過(guò)來(lái)了。一個(gè)簡(jiǎn)單的實(shí)現(xiàn)示例function jsonp(url, callbackName) { return new Promise((resolve, reject) { // 創(chuàng)建全局回調(diào)函數(shù)函數(shù)名需唯一 const funcName jsonpCallback_${Date.now()}; window[funcName] function(data) { resolve(data); // 清理工作 document.body.removeChild(script); delete window[funcName]; }; // 創(chuàng)建script標(biāo)簽 const script document.createElement(script); script.src ${url}${url.includes(?) ? : ?}callback${funcName}; script.onerror reject; // 處理加載失敗 document.body.appendChild(script); }); } // 使用 jsonp(https://api.example.com/data, handleData) .then(data console.log(data)) .catch(err console.error(請(qǐng)求失敗, err));注意事項(xiàng)與局限僅支持 GET 請(qǐng)求這是 JSONP 最致命的限制因?yàn)樗举|(zhì)上是加載一個(gè)腳本資源。安全性問(wèn)題由于引入了外部動(dòng)態(tài)腳本如果服務(wù)器被攻破或返回惡意代碼前端會(huì)直接執(zhí)行存在 XSS跨站腳本攻擊風(fēng)險(xiǎn)。必須絕對(duì)信任服務(wù)器。錯(cuò)誤處理困難script標(biāo)簽的onerror事件能捕獲網(wǎng)絡(luò)錯(cuò)誤但難以處理服務(wù)器返回的業(yè)務(wù)邏輯錯(cuò)誤比如 HTTP 200 但返回了錯(cuò)誤信息。需要服務(wù)器端特殊支持后端必須能夠解析callback參數(shù)并返回特定格式的 JS 代碼。正在被淘汰在現(xiàn)代 Web 開發(fā)中隨著 CORS 標(biāo)準(zhǔn)的完善和廣泛支持JSONP 已逐漸淡出主流視野更多作為一種“歷史知識(shí)”或在不支持 CORS 的極端老舊環(huán)境中使用。2.2 CORS現(xiàn)代跨域通信的“官方協(xié)議”CORSCross-Origin Resource Sharing跨源資源共享是 W3C 標(biāo)準(zhǔn)屬于“官方解決方案”。它允許服務(wù)器聲明哪些源可以訪問(wèn)其資源從而在遵守同源策略的前提下安全地進(jìn)行跨域通信。CORS 的關(guān)鍵在于服務(wù)器端的響應(yīng)頭前端發(fā)起的請(qǐng)求本身并無(wú)特殊除了會(huì)多發(fā)送一些頭信息。CORS 請(qǐng)求的分類 CORS 請(qǐng)求分為兩類簡(jiǎn)單請(qǐng)求和非簡(jiǎn)單請(qǐng)求需預(yù)檢的請(qǐng)求。瀏覽器會(huì)自動(dòng)處理這種區(qū)分。簡(jiǎn)單請(qǐng)求滿足以下所有條件的請(qǐng)求。方法為 GET、HEAD、POST 之一。請(qǐng)求頭僅包含Accept,Accept-Language,Content-Language,Content-Type值僅限于application/x-www-form-urlencoded,multipart/form-data,text/plain。沒有使用ReadableStream對(duì)象等。 對(duì)于簡(jiǎn)單請(qǐng)求瀏覽器直接發(fā)出跨域請(qǐng)求并在請(qǐng)求頭中自動(dòng)添加一個(gè)Origin字段表明請(qǐng)求來(lái)自哪個(gè)源。服務(wù)器需要檢查這個(gè)Origin如果允許就在響應(yīng)頭中包含Access-Control-Allow-Origin: Origin值或*。瀏覽器看到這個(gè)響應(yīng)頭就會(huì)允許前端代碼訪問(wèn)響應(yīng)內(nèi)容。非簡(jiǎn)單請(qǐng)求/預(yù)檢請(qǐng)求不滿足簡(jiǎn)單請(qǐng)求條件的請(qǐng)求例如使用了PUT、DELETE方法或Content-Type為application/json或設(shè)置了自定義頭如Authorization。 對(duì)于這類請(qǐng)求瀏覽器會(huì)先使用OPTIONS方法發(fā)起一個(gè)“預(yù)檢請(qǐng)求”Preflight Request到服務(wù)器以獲知服務(wù)器是否允許該實(shí)際請(qǐng)求。預(yù)檢請(qǐng)求的頭部會(huì)包含Access-Control-Request-Method: 告知服務(wù)器實(shí)際請(qǐng)求將使用的方法。Access-Control-Request-Headers: 告知服務(wù)器實(shí)際請(qǐng)求將攜帶的自定義頭。 服務(wù)器必須響應(yīng)這個(gè) OPTIONS 請(qǐng)求并在響應(yīng)頭中明確聲明允許的方法、頭、源等。只有預(yù)檢請(qǐng)求通過(guò)后瀏覽器才會(huì)發(fā)出真正的請(qǐng)求。服務(wù)器端 CORS 配置示例以 Node.js Express 為例 一個(gè)完整且在生產(chǎn)中建議進(jìn)行細(xì)粒度控制的 CORS 中間件配置如下const express require(express); const app express(); // 允許的源列表生產(chǎn)環(huán)境應(yīng)具體指定避免使用 * const allowedOrigins [https://www.myapp.com, https://admin.myapp.com, http://localhost:3000]; app.use((req, res, next) { const origin req.headers.origin; // 檢查請(qǐng)求源是否在允許列表中 if (allowedOrigins.includes(origin)) { res.setHeader(Access-Control-Allow-Origin, origin); // 動(dòng)態(tài)設(shè)置允許的源 } // 或者為了簡(jiǎn)單測(cè)試可以暫時(shí)允許所有源不推薦生產(chǎn)環(huán)境 // res.setHeader(Access-Control-Allow-Origin, *); // 允許客戶端攜帶的請(qǐng)求頭如 Authorization, Content-Type res.setHeader(Access-Control-Allow-Headers, Content-Type, Authorization, X-Requested-With); // 允許的 HTTP 方法 res.setHeader(Access-Control-Allow-Methods, GET, POST, PUT, PATCH, DELETE, OPTIONS); // 允許瀏覽器暴露哪些響應(yīng)頭給前端 JavaScript如 Authorization res.setHeader(Access-Control-Expose-Headers, Authorization); // 允許跨域請(qǐng)求攜帶 Cookie對(duì)應(yīng)前端 fetch 需要設(shè)置 credentials: include res.setHeader(Access-Control-Allow-Credentials, true); // 預(yù)檢請(qǐng)求緩存時(shí)間秒減少 OPTIONS 請(qǐng)求 res.setHeader(Access-Control-Max-Age, 86400); // 24小時(shí) // 如果是 OPTIONS 預(yù)檢請(qǐng)求直接返回 200 if (req.method OPTIONS) { return res.sendStatus(200); } next(); }); // ... 你的其他路由 app.listen(8080);前端發(fā)起 CORS 請(qǐng)求 使用fetchAPI 時(shí)默認(rèn)行為對(duì)于簡(jiǎn)單請(qǐng)求是透明的。對(duì)于需要憑證Cookies或自定義頭的請(qǐng)求需進(jìn)行配置。// 攜帶 Cookie 的請(qǐng)求 fetch(https://api.example.com/data, { method: GET, credentials: include, // 關(guān)鍵告訴瀏覽器攜帶 Cookie headers: { Content-Type: application/json, Authorization: Bearer ${token} // 自定義頭會(huì)觸發(fā)預(yù)檢 } }) .then(response response.json()) .then(data console.log(data)); // 使用 axios axios.get(https://api.example.com/data, { withCredentials: true, // 等效于 fetch 的 credentials: include headers: { Authorization: Bearer ${token} } });實(shí)操心得不要濫用*在生產(chǎn)環(huán)境中Access-Control-Allow-Origin: *與Access-Control-Allow-Credentials: true是互斥的。如果允許憑證源必須明確指定不能是通配符*。理解預(yù)檢遇到CORS preflight錯(cuò)誤時(shí)首先檢查服務(wù)器是否正確響應(yīng)了OPTIONS請(qǐng)求并設(shè)置了正確的Allow-Methods和Allow-Headers。緩存預(yù)檢合理設(shè)置Access-Control-Max-Age可以減少不必要的 OPTIONS 請(qǐng)求提升性能。錯(cuò)誤處理CORS 錯(cuò)誤發(fā)生在網(wǎng)絡(luò)層面fetch或axios的catch可能捕獲不到瀏覽器直接攔截。需要結(jié)合 Network 面板查看具體的請(qǐng)求和響應(yīng)頭來(lái)調(diào)試。2.3 服務(wù)器代理前端的“萬(wàn)能鑰匙”當(dāng)你不方便修改后端服務(wù)的 CORS 配置例如調(diào)用第三方 API對(duì)方未設(shè)置 CORS 頭或者開發(fā)環(huán)境想徹底避開瀏覽器限制時(shí)服務(wù)器代理是一個(gè)極其有效的方案。其原理很簡(jiǎn)單讓同源的服務(wù)器端去發(fā)起跨域請(qǐng)求然后將結(jié)果返回給前端。因?yàn)橥床呗灾幌拗茷g覽器不限制服務(wù)器。實(shí)現(xiàn)方式開發(fā)服務(wù)器代理現(xiàn)代前端構(gòu)建工具如 Vite、Webpack Dev Server都內(nèi)置了強(qiáng)大的代理功能。Vite 示例(vite.config.js)export default defineConfig({ server: { proxy: { // 將 /api 開頭的請(qǐng)求代理到目標(biāo)服務(wù)器 /api: { target: http://localhost:8080, // 后端 API 地址 changeOrigin: true, // 修改請(qǐng)求頭中的 Host 為目標(biāo)地址通常需要開啟 rewrite: (path) path.replace(/^\/api/, ) // 重寫路徑可選 } } } })配置后前端代碼中請(qǐng)求/api/users實(shí)際上會(huì)被 Vite 開發(fā)服務(wù)器代理到http://localhost:8080/users完美繞過(guò)瀏覽器跨域。Webpack Dev Server 示例(webpack.config.js)module.exports { // ... devServer: { proxy: { /api: http://localhost:8080 } } };生產(chǎn)環(huán)境反向代理在生產(chǎn)環(huán)境中通常使用 Nginx 或 Apache 等 Web 服務(wù)器作為反向代理。Nginx 配置示例server { listen 80; server_name www.myapp.com; location / { root /path/to/your/frontend/dist; index index.html; try_files $uri $uri/ /index.html; # 用于支持前端路由 } # 代理到后端 API 服務(wù)器 location /api/ { proxy_pass http://backend-server:8080/; # 后端服務(wù)地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }這樣用戶訪問(wèn)www.myapp.comNginx 服務(wù)前端靜態(tài)文件當(dāng)前端請(qǐng)求www.myapp.com/api/xxx時(shí)Nginx 會(huì)將其透明地轉(zhuǎn)發(fā)到內(nèi)部的backend-server:8080上對(duì)瀏覽器而言所有請(qǐng)求都是同源的。注意事項(xiàng)非銀彈代理解決的是前端開發(fā)時(shí)的跨域問(wèn)題或者在生產(chǎn)中統(tǒng)一入口。它并沒有改變跨域的本質(zhì)只是把跨域請(qǐng)求的發(fā)起者從瀏覽器移到了服務(wù)器。安全性如果代理的是不受信任的第三方服務(wù)需要小心處理請(qǐng)求和響應(yīng)防止被用作攻擊跳板。Cookie 與頭信息配置代理時(shí)需要注意正確傳遞原始請(qǐng)求的 Cookie、認(rèn)證頭等信息如上述 Nginx 配置中的proxy_set_header。3. 其他跨域技術(shù)與實(shí)戰(zhàn)場(chǎng)景除了上述三大主流方案還有一些特定場(chǎng)景下使用的跨域技術(shù)了解它們可以讓你在遇到特殊問(wèn)題時(shí)多一種思路。3.1postMessage跨文檔通信的“標(biāo)準(zhǔn)通道”window.postMessage()方法提供了一種安全的、受控的機(jī)制允許不同源的窗口/iframe 之間進(jìn)行通信。這在需要嵌入第三方組件如地圖、支付、客服插件或?qū)崿F(xiàn)多頁(yè)面應(yīng)用通信時(shí)非常有用。基本用法// 發(fā)送方 (例如父頁(yè)面) const iframe document.getElementById(myIframe); const targetWindow iframe.contentWindow; const targetOrigin https://trusted-site.com; // 必須指定目標(biāo)源出于安全考慮 // 發(fā)送消息 targetWindow.postMessage({ type: USER_DATA, payload: userInfo }, targetOrigin); // 接收方 (例如 iframe 內(nèi)的頁(yè)面) window.addEventListener(message, (event) { // 重要?jiǎng)?wù)必驗(yàn)證消息來(lái)源 if (event.origin ! https://parent-site.com) { // 忽略來(lái)自未知源的消息 return; } console.log(收到消息:, event.data); // 處理消息... });關(guān)鍵點(diǎn)安全性postMessage的第一個(gè)參數(shù)targetOrigin和接收方的event.origin檢查至關(guān)重要可以防止惡意網(wǎng)站攔截或發(fā)送偽造消息。異步通信是異步的基于事件監(jiān)聽。結(jié)構(gòu)化克隆算法可以傳遞能夠被結(jié)構(gòu)化克隆算法處理的任何對(duì)象包括大多數(shù)原生類型、對(duì)象、數(shù)組但不能傳遞函數(shù)、DOM 元素等。3.2 修改document.domain同主域下的“捷徑”這是一個(gè)非常受限且逐漸被廢棄的方法。它只適用于一種特殊情況兩個(gè)頁(yè)面擁有相同的頂級(jí)域名和相同的二級(jí)域名只是子域名不同。例如a.example.com和b.example.com。原理通過(guò)將兩個(gè)頁(yè)面的document.domain都設(shè)置為example.com瀏覽器會(huì)認(rèn)為它們同源從而允許直接訪問(wèn)彼此的 DOM 和 Cookie。// 在 a.example.com 和 b.example.com 的頁(yè)面中都執(zhí)行 document.domain example.com;嚴(yán)重限制只能設(shè)置為當(dāng)前域或其父域。一旦設(shè)置無(wú)法再改回更具體的子域。端口號(hào)會(huì)被忽略如果端口不同仍可能有問(wèn)題。現(xiàn)代瀏覽器出于安全考慮對(duì)此方法的限制越來(lái)越多不推薦在新項(xiàng)目中使用。3.3 WebSocket不受同源策略限制的“特例”WebSocket 協(xié)議 (ws://或wss://) 在建立連接時(shí)使用的 HTTP 升級(jí)握手請(qǐng)求受同源策略約束。但是一旦連接建立后續(xù)通過(guò)該連接進(jìn)行的雙向數(shù)據(jù)傳輸不受同源策略限制。這意味著你可以通過(guò)一個(gè) WebSocket 連接與任何源的服務(wù)器進(jìn)行實(shí)時(shí)通信。不過(guò)服務(wù)器端仍然可以在握手階段通過(guò)檢查Origin頭來(lái)決定是否接受連接這是一種應(yīng)用層的安全控制。4. 跨域?qū)崙?zhàn)從開發(fā)到部署的完整鏈路理解了各種方案我們需要將其串聯(lián)到實(shí)際的工作流中。一個(gè)典型的前后端分離項(xiàng)目跨域處理會(huì)貫穿開發(fā)、測(cè)試、部署全流程。4.1 開發(fā)環(huán)境的最佳實(shí)踐在開發(fā)階段我們的核心訴求是高效、無(wú)阻塞地調(diào)試。推薦組合使用以下方案首選開發(fā)服務(wù)器代理配置 Vite/Webpack Dev Server 的代理。這是最干凈、最模擬生產(chǎn)環(huán)境的方式。前端代碼中直接使用相對(duì)路徑如/api/user或配置一個(gè)基礎(chǔ) URL由開發(fā)服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)到真正的后端地址。這樣做的好處是前端代碼無(wú)需關(guān)心環(huán)境差異與生產(chǎn)環(huán)境的調(diào)用方式保持一致。臨時(shí)禁用瀏覽器安全策略僅限本地這是一個(gè)極其不推薦但有時(shí)用于快速驗(yàn)證的臨時(shí)方法。絕對(duì)不要將其作為解決方案更不要指導(dǎo)用戶這樣做。Chrome通過(guò)命令行啟動(dòng)chrome.exe --disable-web-security --user-data-dirC:\TempChrome。這會(huì)關(guān)閉所有同源策略檢查非常危險(xiǎn)僅用于臨時(shí)測(cè)試。瀏覽器插件存在一些允許臨時(shí)禁用 CORS 的插件同樣只應(yīng)在完全可控的本地環(huán)境使用。重要警告禁用瀏覽器安全策略會(huì)讓你暴露在各種網(wǎng)絡(luò)攻擊風(fēng)險(xiǎn)下僅可作為最后手段的臨時(shí)測(cè)試且測(cè)試后應(yīng)立即關(guān)閉。在任何正式開發(fā)、測(cè)試或生產(chǎn)指導(dǎo)中都不應(yīng)提及此方法。后端開啟寬松 CORS用于開發(fā)讓后端同學(xué)在開發(fā)環(huán)境的代碼中配置允許來(lái)自本地前端開發(fā)服務(wù)器地址如http://localhost:3000的跨域請(qǐng)求。這需要后端配合是比代理更“正式”一點(diǎn)的開發(fā)環(huán)境方案。實(shí)操心得在團(tuán)隊(duì)中將開發(fā)服務(wù)器的代理配置寫入項(xiàng)目文檔或README.md是新成員快速上手的關(guān)鍵一步。確保vite.config.js或webpack.config.js中的代理配置清晰、準(zhǔn)確。4.2 生產(chǎn)環(huán)境的架構(gòu)設(shè)計(jì)生產(chǎn)環(huán)境中跨域問(wèn)題主要通過(guò)后端和基礎(chǔ)設(shè)施層面解決前端代碼應(yīng)保持“無(wú)感知”。標(biāo)準(zhǔn)方案后端配置 CORS這是最主流、最推薦的方式。后端服務(wù)在響應(yīng)中設(shè)置精確的Access-Control-Allow-Origin等頭部。例如允許你的前端域名https://www.myapp.com和https://admin.myapp.com。切勿在生產(chǎn)環(huán)境使用*除非是完全公開的、無(wú)需憑證的 API如公開的天氣 API。架構(gòu)方案API 網(wǎng)關(guān) / 反向代理在微服務(wù)或復(fù)雜架構(gòu)中通常會(huì)在前端和后端服務(wù)之間設(shè)立一個(gè) API 網(wǎng)關(guān)如 Kong, Apigee或使用 Nginx 作為反向代理。所有前端請(qǐng)求都發(fā)往同一個(gè)域名網(wǎng)關(guān)域名由網(wǎng)關(guān)負(fù)責(zé)路由到內(nèi)部各個(gè)微服務(wù)并在網(wǎng)關(guān)層面統(tǒng)一處理 CORS 策略、認(rèn)證、限流等。這樣前端完全不用處理跨域后端各服務(wù)也無(wú)需單獨(dú)配置 CORS。CDN 與靜態(tài)資源對(duì)于圖片、字體、樣式等靜態(tài)資源的跨域可能會(huì)遇到字體文件的 CORS 問(wèn)題font-face。通常的解決方案是在存放靜態(tài)資源的服務(wù)器如 OSS、S3、Nginx上配置 CORS 頭。使用 CDN 服務(wù)并在 CDN 配置中開啟 CORS 支持。對(duì)于字體文件除了 CORS 頭可能還需要設(shè)置Access-Control-Allow-Origin和正確的Content-Type。4.3 文件上傳與跨域的特殊處理文件上傳是一個(gè)常見的跨域難點(diǎn)因?yàn)橥ǔＩ婕癿ultipart/form-data格式和可能的大文件傳輸。方案一通過(guò)表單直接提交到目標(biāo)域名。這是最傳統(tǒng)的方式表單的action直接指向目標(biāo)服務(wù)器表單提交本身不受同源策略限制。但這種方式用戶體驗(yàn)差無(wú)法在前端做預(yù)覽、進(jìn)度提示等。方案二前端直傳 OSS推薦對(duì)于上傳到云存儲(chǔ)如阿里云 OSS、AWS S3的場(chǎng)景最佳實(shí)踐是前端直接從瀏覽器上傳到 OSS而不是經(jīng)過(guò)自己的應(yīng)用服務(wù)器中轉(zhuǎn)。流程通常是前端向自己的應(yīng)用服務(wù)器申請(qǐng)一個(gè)臨時(shí)的、有時(shí)效性的上傳憑證STS Token 或預(yù)簽名 URL。前端使用這個(gè)憑證直接調(diào)用 OSS 的 SDK 或使用表單直傳 API 將文件上傳到 OSS。OSS 服務(wù)需要配置允許前端頁(yè)面所在域名的 CORS。在 OSS 控制臺(tái)可以配置詳細(xì)的 CORS 規(guī)則允許PUT、POST等方法以及必要的頭信息。// 以阿里云 OSS 瀏覽器直傳為例簡(jiǎn)化 // 1. 從自己服務(wù)器獲取簽名和 policy const { signature, policy, ossHost, key } await getUploadTokenFromMyServer(); // 2. 構(gòu)建表單數(shù)據(jù) const formData new FormData(); formData.append(key, key); formData.append(policy, policy); formData.append(OSSAccessKeyId, your-temp-access-key-id); formData.append(signature, signature); formData.append(file, fileObject); // 文件對(duì)象 // 3. 直接 POST 到 OSS跨域請(qǐng)求OSS 已配置 CORS const response await fetch(ossHost, { method: POST, body: formData });方案三自己的服務(wù)器代理上傳。如果必須上傳到自己的服務(wù)器且服務(wù)器已正確配置 CORS允許Content-Type: multipart/form-data那么使用FormData配合fetch或axios上傳即可瀏覽器會(huì)自動(dòng)處理預(yù)檢請(qǐng)求。5. 深度排查當(dāng) CORS 依然報(bào)錯(cuò)時(shí)即使你認(rèn)為已經(jīng)正確配置了 CORS瀏覽器可能依然會(huì)拋出錯(cuò)誤。以下是一個(gè)系統(tǒng)性的排查清單幫助你定位問(wèn)題根源。5.1 預(yù)檢請(qǐng)求OPTIONS失敗這是最常見的問(wèn)題之一。癥狀是 Network 面板中能看到一個(gè)OPTIONS請(qǐng)求并且它返回了非 2xx 狀態(tài)碼如 404, 405, 500或者響應(yīng)頭中缺少必要的 CORS 頭。排查步驟檢查服務(wù)器是否響應(yīng) OPTIONS 方法很多后端框架的路由默認(rèn)只配置了GET,POST,PUT,DELETE漏掉了OPTIONS。你需要確保你的路由或全局中間件能正確處理OPTIONS請(qǐng)求并返回正確的 CORS 頭。檢查Access-Control-Allow-Methods確保它包含了實(shí)際請(qǐng)求所使用的 HTTP 方法如PUT,DELETE。檢查Access-Control-Allow-Headers確保它包含了前端請(qǐng)求中出現(xiàn)的所有自定義頭如Authorization,X-Custom-Header。像Content-Type為application/json時(shí)也需要將其加入允許的頭部列表。檢查Access-Control-Max-Age如果設(shè)置了這個(gè)頭瀏覽器會(huì)緩存預(yù)檢結(jié)果。在調(diào)試時(shí)可以暫時(shí)將其設(shè)置為0或移除以確保每次請(qǐng)求都發(fā)送預(yù)檢方便看到最新改動(dòng)。5.2 憑證Cookies與Access-Control-Allow-Origin沖突錯(cuò)誤現(xiàn)象前端設(shè)置了credentials: ‘include‘但服務(wù)器響應(yīng)頭Access-Control-Allow-Origin的值是通配符*。瀏覽器控制臺(tái)報(bào)錯(cuò)The value of the ‘Access-Control-Allow-Origin‘ header in the response must not be the wildcard ‘*‘ when the request‘s credentials mode is ‘include‘.解決方案服務(wù)器必須返回一個(gè)明確的、具體的源如https://www.myapp.com而不能是*。同時(shí)響應(yīng)頭中必須包含Access-Control-Allow-Credentials: true。5.3 響應(yīng)頭未暴露給前端錯(cuò)誤現(xiàn)象前端可以收到響應(yīng)但無(wú)法通過(guò)response.headers.get(‘My-Header‘)讀取某些自定義響應(yīng)頭。原因默認(rèn)情況下瀏覽器只將簡(jiǎn)單響應(yīng)頭Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma暴露給前端 JavaScript。其他自定義頭如Authorization,X-Pagination-Total需要服務(wù)器通過(guò)Access-Control-Expose-Headers頭顯式暴露。解決方案在服務(wù)器響應(yīng)頭中添加Access-Control-Expose-Headers: ‘Authorization, X-Pagination-Total‘。5.4 攜帶 Cookie 的請(qǐng)求Origin 檢查失敗錯(cuò)誤現(xiàn)象請(qǐng)求攜帶了 Cookie但服務(wù)器檢查Origin頭后發(fā)現(xiàn)不在白名單內(nèi)因此拒絕了請(qǐng)求。排查確保服務(wù)器端的 CORS 中間件邏輯正確。當(dāng)使用credentials: ‘include‘時(shí)前端的fetch請(qǐng)求會(huì)始終攜帶Origin頭。服務(wù)器的邏輯應(yīng)該是讀取req.headers.origin判斷其是否在允許的源列表中如果在則設(shè)置Access-Control-Allow-Origin為該具體的源值不能是*。5.5 使用工具進(jìn)行網(wǎng)絡(luò)分析開發(fā)者工具 (Network Panel) 是你的最佳朋友打開Preserve log保留日志防止頁(yè)面跳轉(zhuǎn)請(qǐng)求被清除。找到出錯(cuò)的請(qǐng)求點(diǎn)擊查看Headers標(biāo)簽。仔細(xì)對(duì)比「Request Headers」和「Response Headers」。Request Headers查看Origin頭是否正確發(fā)送。查看Access-Control-Request-Method和Access-Control-Request-Headers僅在預(yù)檢請(qǐng)求中出現(xiàn)。Response Headers這是排查重點(diǎn)。逐一核對(duì)Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers,Access-Control-Allow-Credentials,Access-Control-Expose-Headers是否存在且值正確。查看Response標(biāo)簽和Console標(biāo)簽中的完整錯(cuò)誤信息?？缬騿?wèn)題本質(zhì)上是前后端協(xié)同的協(xié)議問(wèn)題。前端需要知道如何發(fā)起合規(guī)的請(qǐng)求如設(shè)置credentials后端必須響應(yīng)以正確的許可頭。掌握這套“握手”規(guī)則并善用瀏覽器開發(fā)者工具進(jìn)行調(diào)試絕大多數(shù)跨域難題都能迎刃而解。記住安全是前提所有的解決方案都應(yīng)在同源策略的框架內(nèi)為合法的跨源通信開一扇窗而不是拆掉整面墻。 前端跨域通信全解析：從同源策略到CORS、JSONP與服務(wù)器代理實(shí)戰(zhàn)
1. 同源策略前端世界的“安全門衛(wèi)”做前端開發(fā)只要和瀏覽器打交道就繞不開“同源策略”這四個(gè)字。它就像瀏覽器內(nèi)置的一位鐵面無(wú)私的門衛(wèi)時(shí)刻審視著每一個(gè)進(jìn)出頁(yè)面的請(qǐng)求決定是放行還是攔截。簡(jiǎn)單來(lái)說(shuō)同源策略是一種核心的安全機(jī)制它規(guī)定了一個(gè)源Origin加載的文檔或腳本如何與另一個(gè)源的資源進(jìn)行交互。它的存在從根本上防止了惡意網(wǎng)站竊取用戶在其他網(wǎng)站比如你的銀行或郵箱的敏感數(shù)據(jù)。對(duì)于前端開發(fā)者而言理解這位“門衛(wèi)”的規(guī)則并學(xué)會(huì)在合規(guī)的前提下與“鄰居”其他源安全通信是一項(xiàng)必備技能。那么什么是“同源”判斷標(biāo)準(zhǔn)非常嚴(yán)格必須同時(shí)滿足三個(gè)要素完全相同協(xié)議、域名、端口。只要有一個(gè)不同就被視為“跨源”或我們常說(shuō)的“跨域”。舉個(gè)例子https://www.example.com:443這個(gè)源它與以下地址的關(guān)系是https://www.example.com:8080-不同源端口不同http://www.example.com:443-不同源協(xié)議不同https://api.example.com:443-不同源域名不同子域名也算不同源https://www.example.com:443/path/to/page-同源僅路徑不同不影響同源判斷這位“門衛(wèi)”主要限制以下幾種行為1) 無(wú)法讀取非同源網(wǎng)頁(yè)的 Cookie、LocalStorage 和 IndexedDB2) 無(wú)法獲取非同源網(wǎng)頁(yè)的 DOM 元素典型的如iframe嵌套不同源頁(yè)面3) 限制通過(guò)XMLHttpRequest或Fetch API發(fā)起的跨源 HTTP 請(qǐng)求。最后一點(diǎn)正是我們?nèi)粘ｉ_發(fā)中遇到“跨域問(wèn)題”最常見的場(chǎng)景。當(dāng)你從localhost:3000的前端項(xiàng)目去請(qǐng)求localhost:8080的后端 API 時(shí)瀏覽器控制臺(tái)那個(gè)經(jīng)典的CORS policy錯(cuò)誤就出現(xiàn)了。理解它不是為了對(duì)抗它而是為了在它的規(guī)則下安全、優(yōu)雅地實(shí)現(xiàn)業(yè)務(wù)需求。1.1 為什么需要同源策略一個(gè)生動(dòng)的比喻為了更直觀地理解我們可以把互聯(lián)網(wǎng)想象成一個(gè)巨大的社區(qū)每個(gè)網(wǎng)站源就是社區(qū)里的一棟房子。你的房子https://your-bank.com里有你的保險(xiǎn)柜Cookie、登錄態(tài)、私人文件DOM和電話AJAX請(qǐng)求。如果沒有同源策略這個(gè)社區(qū)保安會(huì)發(fā)生什么一個(gè)偽裝成送快遞的惡意網(wǎng)站http://evil-site.com可以輕易地打開你家的窗戶通過(guò)腳本偷看你的保險(xiǎn)柜密碼翻閱你的私人文件甚至用你的電話冒充你給銀行打電話轉(zhuǎn)賬。這無(wú)疑是災(zāi)難性的。同源策略的作用就是給每棟房子裝上安全鎖和監(jiān)控。它規(guī)定只有從你自己房子內(nèi)部發(fā)出的指令才能操作你自己房子的東西。來(lái)自其他房子的快遞員腳本只能按門鈴發(fā)起請(qǐng)求但未經(jīng)你明確許可CORS機(jī)制絕對(duì)不能進(jìn)門更不能亂動(dòng)你的物品。這樣即使你不小心訪問(wèn)了惡意網(wǎng)站它也無(wú)法直接竊取你在其他重要網(wǎng)站如銀行、郵箱的會(huì)話信息極大地保護(hù)了用戶的數(shù)據(jù)安全和隱私。作為開發(fā)者我們的任務(wù)不是拆掉這把鎖而是學(xué)會(huì)如何正確地使用“訪客登記系統(tǒng)”讓合法的、我們需要的“訪客”如后端API、第三方服務(wù)能夠安全地進(jìn)來(lái)。1.2 跨域請(qǐng)求的典型場(chǎng)景與錯(cuò)誤在實(shí)際開發(fā)中跨域請(qǐng)求無(wú)處不在尤其是在前后端分離的架構(gòu)下。以下是一些典型場(chǎng)景本地開發(fā)前端運(yùn)行在http://localhost:3000后端 API 服務(wù)運(yùn)行在http://localhost:8080。多環(huán)境部署Web 應(yīng)用部署在https://www.myapp.com而靜態(tài)資源圖片、字體或 API 服務(wù)器部署在獨(dú)立的域名https://cdn.myapp.com或https://api.myapp.com。第三方服務(wù)集成你的網(wǎng)站需要調(diào)用地圖 API如高德、百度、支付接口如支付寶、微信支付、社交登錄如微信、微博 OAuth等這些服務(wù)的域名與你自己的站點(diǎn)域名必然不同。當(dāng)瀏覽器攔截了一個(gè)跨域請(qǐng)求時(shí)你會(huì)在開發(fā)者工具的 Console 或 Network 面板中看到明確的錯(cuò)誤信息。最常見的就是 CORS 相關(guān)錯(cuò)誤例如Access to fetch at ‘https://api.example.com/data‘ from origin ‘https://www.myapp.com‘ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin‘ header is present on the requested resource.或者更詳細(xì)的預(yù)檢請(qǐng)求錯(cuò)誤Access to fetch at ... has been blocked by CORS policy: Response to preflight request doesn‘t pass access control check: It does not have HTTP ok status.這些紅色的錯(cuò)誤日志正是同源策略這位“門衛(wèi)”在盡職盡責(zé)地提醒你當(dāng)前請(qǐng)求未獲得目標(biāo)服務(wù)器的明確許可。解決這些錯(cuò)誤就是我們接下來(lái)要探討的核心。2. 經(jīng)典跨域解決方案深度剖析面對(duì)跨域限制前端社區(qū)發(fā)展出了多種解決方案。每種方案都有其特定的適用場(chǎng)景、實(shí)現(xiàn)原理和優(yōu)缺點(diǎn)。我們不能只會(huì)調(diào)用axios或fetch更要理解背后發(fā)生了什么。這里我們深入剖析幾種最經(jīng)典、最常用的方案。2.1 JSONP基于script標(biāo)簽的“歷史智慧”JSONPJSON with Padding是一種非常古老但一度非常流行的跨域技術(shù)。它巧妙地利用了 HTML 中script標(biāo)簽的一個(gè)特性其src屬性可以跨域加載 JavaScript 文件。瀏覽器不會(huì)對(duì)script標(biāo)簽的跨域加載施加同源策略限制。實(shí)現(xiàn)原理前端不直接發(fā)起 AJAX 請(qǐng)求而是動(dòng)態(tài)創(chuàng)建一個(gè)script標(biāo)簽。將這個(gè)script標(biāo)簽的src屬性設(shè)置為目標(biāo) API 的 URL并在 URL 上通過(guò)查詢參數(shù)通常是callback指定一個(gè)全局回調(diào)函數(shù)名例如https://api.example.com/data?callbackhandleResponse。將這個(gè)script標(biāo)簽插入到 DOM 中瀏覽器就會(huì)去請(qǐng)求這個(gè) URL。服務(wù)器端需要配合這個(gè)約定。它接收到請(qǐng)求后不是返回標(biāo)準(zhǔn)的 JSON而是返回一段JavaScript 代碼這段代碼的內(nèi)容是調(diào)用前端指定的那個(gè)回調(diào)函數(shù)并將真正的數(shù)據(jù)作為參數(shù)傳入。例如返回handleResponse({status: ok, data: {...}})。瀏覽器加載并執(zhí)行這段返回的 JS 代碼自然就調(diào)用了前端的handleResponse函數(shù)數(shù)據(jù)就這樣“跨域”傳遞過(guò)來(lái)了。一個(gè)簡(jiǎn)單的實(shí)現(xiàn)示例function jsonp(url, callbackName) { return new Promise((resolve, reject) { // 創(chuàng)建全局回調(diào)函數(shù)函數(shù)名需唯一 const funcName jsonpCallback_${Date.now()}; window[funcName] function(data) { resolve(data); // 清理工作 document.body.removeChild(script); delete window[funcName]; }; // 創(chuàng)建script標(biāo)簽 const script document.createElement(script); script.src ${url}${url.includes(?) ? : ?}callback${funcName}; script.onerror reject; // 處理加載失敗 document.body.appendChild(script); }); } // 使用 jsonp(https://api.example.com/data, handleData) .then(data console.log(data)) .catch(err console.error(請(qǐng)求失敗, err));注意事項(xiàng)與局限僅支持 GET 請(qǐng)求這是 JSONP 最致命的限制因?yàn)樗举|(zhì)上是加載一個(gè)腳本資源。安全性問(wèn)題由于引入了外部動(dòng)態(tài)腳本如果服務(wù)器被攻破或返回惡意代碼前端會(huì)直接執(zhí)行存在 XSS跨站腳本攻擊風(fēng)險(xiǎn)。必須絕對(duì)信任服務(wù)器。錯(cuò)誤處理困難script標(biāo)簽的onerror事件能捕獲網(wǎng)絡(luò)錯(cuò)誤但難以處理服務(wù)器返回的業(yè)務(wù)邏輯錯(cuò)誤比如 HTTP 200 但返回了錯(cuò)誤信息。需要服務(wù)器端特殊支持后端必須能夠解析callback參數(shù)并返回特定格式的 JS 代碼。正在被淘汰在現(xiàn)代 Web 開發(fā)中隨著 CORS 標(biāo)準(zhǔn)的完善和廣泛支持JSONP 已逐漸淡出主流視野更多作為一種“歷史知識(shí)”或在不支持 CORS 的極端老舊環(huán)境中使用。2.2 CORS現(xiàn)代跨域通信的“官方協(xié)議”CORSCross-Origin Resource Sharing跨源資源共享是 W3C 標(biāo)準(zhǔn)屬于“官方解決方案”。它允許服務(wù)器聲明哪些源可以訪問(wèn)其資源從而在遵守同源策略的前提下安全地進(jìn)行跨域通信。CORS 的關(guān)鍵在于服務(wù)器端的響應(yīng)頭前端發(fā)起的請(qǐng)求本身并無(wú)特殊除了會(huì)多發(fā)送一些頭信息。CORS 請(qǐng)求的分類 CORS 請(qǐng)求分為兩類簡(jiǎn)單請(qǐng)求和非簡(jiǎn)單請(qǐng)求需預(yù)檢的請(qǐng)求。瀏覽器會(huì)自動(dòng)處理這種區(qū)分。簡(jiǎn)單請(qǐng)求滿足以下所有條件的請(qǐng)求。方法為 GET、HEAD、POST 之一。請(qǐng)求頭僅包含Accept,Accept-Language,Content-Language,Content-Type值僅限于application/x-www-form-urlencoded,multipart/form-data,text/plain。沒有使用ReadableStream對(duì)象等。 對(duì)于簡(jiǎn)單請(qǐng)求瀏覽器直接發(fā)出跨域請(qǐng)求并在請(qǐng)求頭中自動(dòng)添加一個(gè)Origin字段表明請(qǐng)求來(lái)自哪個(gè)源。服務(wù)器需要檢查這個(gè)Origin如果允許就在響應(yīng)頭中包含Access-Control-Allow-Origin: Origin值或*。瀏覽器看到這個(gè)響應(yīng)頭就會(huì)允許前端代碼訪問(wèn)響應(yīng)內(nèi)容。非簡(jiǎn)單請(qǐng)求/預(yù)檢請(qǐng)求不滿足簡(jiǎn)單請(qǐng)求條件的請(qǐng)求例如使用了PUT、DELETE方法或Content-Type為application/json或設(shè)置了自定義頭如Authorization。 對(duì)于這類請(qǐng)求瀏覽器會(huì)先使用OPTIONS方法發(fā)起一個(gè)“預(yù)檢請(qǐng)求”Preflight Request到服務(wù)器以獲知服務(wù)器是否允許該實(shí)際請(qǐng)求。預(yù)檢請(qǐng)求的頭部會(huì)包含Access-Control-Request-Method: 告知服務(wù)器實(shí)際請(qǐng)求將使用的方法。Access-Control-Request-Headers: 告知服務(wù)器實(shí)際請(qǐng)求將攜帶的自定義頭。 服務(wù)器必須響應(yīng)這個(gè) OPTIONS 請(qǐng)求并在響應(yīng)頭中明確聲明允許的方法、頭、源等。只有預(yù)檢請(qǐng)求通過(guò)后瀏覽器才會(huì)發(fā)出真正的請(qǐng)求。服務(wù)器端 CORS 配置示例以 Node.js Express 為例 一個(gè)完整且在生產(chǎn)中建議進(jìn)行細(xì)粒度控制的 CORS 中間件配置如下const express require(express); const app express(); // 允許的源列表生產(chǎn)環(huán)境應(yīng)具體指定避免使用 * const allowedOrigins [https://www.myapp.com, https://admin.myapp.com, http://localhost:3000]; app.use((req, res, next) { const origin req.headers.origin; // 檢查請(qǐng)求源是否在允許列表中 if (allowedOrigins.includes(origin)) { res.setHeader(Access-Control-Allow-Origin, origin); // 動(dòng)態(tài)設(shè)置允許的源 } // 或者為了簡(jiǎn)單測(cè)試可以暫時(shí)允許所有源不推薦生產(chǎn)環(huán)境 // res.setHeader(Access-Control-Allow-Origin, *); // 允許客戶端攜帶的請(qǐng)求頭如 Authorization, Content-Type res.setHeader(Access-Control-Allow-Headers, Content-Type, Authorization, X-Requested-With); // 允許的 HTTP 方法 res.setHeader(Access-Control-Allow-Methods, GET, POST, PUT, PATCH, DELETE, OPTIONS); // 允許瀏覽器暴露哪些響應(yīng)頭給前端 JavaScript如 Authorization res.setHeader(Access-Control-Expose-Headers, Authorization); // 允許跨域請(qǐng)求攜帶 Cookie對(duì)應(yīng)前端 fetch 需要設(shè)置 credentials: include res.setHeader(Access-Control-Allow-Credentials, true); // 預(yù)檢請(qǐng)求緩存時(shí)間秒減少 OPTIONS 請(qǐng)求 res.setHeader(Access-Control-Max-Age, 86400); // 24小時(shí) // 如果是 OPTIONS 預(yù)檢請(qǐng)求直接返回 200 if (req.method OPTIONS) { return res.sendStatus(200); } next(); }); // ... 你的其他路由 app.listen(8080);前端發(fā)起 CORS 請(qǐng)求 使用fetchAPI 時(shí)默認(rèn)行為對(duì)于簡(jiǎn)單請(qǐng)求是透明的。對(duì)于需要憑證Cookies或自定義頭的請(qǐng)求需進(jìn)行配置。// 攜帶 Cookie 的請(qǐng)求 fetch(https://api.example.com/data, { method: GET, credentials: include, // 關(guān)鍵告訴瀏覽器攜帶 Cookie headers: { Content-Type: application/json, Authorization: Bearer ${token} // 自定義頭會(huì)觸發(fā)預(yù)檢 } }) .then(response response.json()) .then(data console.log(data)); // 使用 axios axios.get(https://api.example.com/data, { withCredentials: true, // 等效于 fetch 的 credentials: include headers: { Authorization: Bearer ${token} } });實(shí)操心得不要濫用*在生產(chǎn)環(huán)境中Access-Control-Allow-Origin: *與Access-Control-Allow-Credentials: true是互斥的。如果允許憑證源必須明確指定不能是通配符*。理解預(yù)檢遇到CORS preflight錯(cuò)誤時(shí)首先檢查服務(wù)器是否正確響應(yīng)了OPTIONS請(qǐng)求并設(shè)置了正確的Allow-Methods和Allow-Headers。緩存預(yù)檢合理設(shè)置Access-Control-Max-Age可以減少不必要的 OPTIONS 請(qǐng)求提升性能。錯(cuò)誤處理CORS 錯(cuò)誤發(fā)生在網(wǎng)絡(luò)層面fetch或axios的catch可能捕獲不到瀏覽器直接攔截。需要結(jié)合 Network 面板查看具體的請(qǐng)求和響應(yīng)頭來(lái)調(diào)試。2.3 服務(wù)器代理前端的“萬(wàn)能鑰匙”當(dāng)你不方便修改后端服務(wù)的 CORS 配置例如調(diào)用第三方 API對(duì)方未設(shè)置 CORS 頭或者開發(fā)環(huán)境想徹底避開瀏覽器限制時(shí)服務(wù)器代理是一個(gè)極其有效的方案。其原理很簡(jiǎn)單讓同源的服務(wù)器端去發(fā)起跨域請(qǐng)求然后將結(jié)果返回給前端。因?yàn)橥床呗灾幌拗茷g覽器不限制服務(wù)器。實(shí)現(xiàn)方式開發(fā)服務(wù)器代理現(xiàn)代前端構(gòu)建工具如 Vite、Webpack Dev Server都內(nèi)置了強(qiáng)大的代理功能。Vite 示例(vite.config.js)export default defineConfig({ server: { proxy: { // 將 /api 開頭的請(qǐng)求代理到目標(biāo)服務(wù)器 /api: { target: http://localhost:8080, // 后端 API 地址 changeOrigin: true, // 修改請(qǐng)求頭中的 Host 為目標(biāo)地址通常需要開啟 rewrite: (path) path.replace(/^\/api/, ) // 重寫路徑可選 } } } })配置后前端代碼中請(qǐng)求/api/users實(shí)際上會(huì)被 Vite 開發(fā)服務(wù)器代理到http://localhost:8080/users完美繞過(guò)瀏覽器跨域。Webpack Dev Server 示例(webpack.config.js)module.exports { // ... devServer: { proxy: { /api: http://localhost:8080 } } };生產(chǎn)環(huán)境反向代理在生產(chǎn)環(huán)境中通常使用 Nginx 或 Apache 等 Web 服務(wù)器作為反向代理。Nginx 配置示例server { listen 80; server_name www.myapp.com; location / { root /path/to/your/frontend/dist; index index.html; try_files $uri $uri/ /index.html; # 用于支持前端路由 } # 代理到后端 API 服務(wù)器 location /api/ { proxy_pass http://backend-server:8080/; # 后端服務(wù)地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }這樣用戶訪問(wèn)www.myapp.comNginx 服務(wù)前端靜態(tài)文件當(dāng)前端請(qǐng)求www.myapp.com/api/xxx時(shí)Nginx 會(huì)將其透明地轉(zhuǎn)發(fā)到內(nèi)部的backend-server:8080上對(duì)瀏覽器而言所有請(qǐng)求都是同源的。注意事項(xiàng)非銀彈代理解決的是前端開發(fā)時(shí)的跨域問(wèn)題或者在生產(chǎn)中統(tǒng)一入口。它并沒有改變跨域的本質(zhì)只是把跨域請(qǐng)求的發(fā)起者從瀏覽器移到了服務(wù)器。安全性如果代理的是不受信任的第三方服務(wù)需要小心處理請(qǐng)求和響應(yīng)防止被用作攻擊跳板。Cookie 與頭信息配置代理時(shí)需要注意正確傳遞原始請(qǐng)求的 Cookie、認(rèn)證頭等信息如上述 Nginx 配置中的proxy_set_header。3. 其他跨域技術(shù)與實(shí)戰(zhàn)場(chǎng)景除了上述三大主流方案還有一些特定場(chǎng)景下使用的跨域技術(shù)了解它們可以讓你在遇到特殊問(wèn)題時(shí)多一種思路。3.1postMessage跨文檔通信的“標(biāo)準(zhǔn)通道”window.postMessage()方法提供了一種安全的、受控的機(jī)制允許不同源的窗口/iframe 之間進(jìn)行通信。這在需要嵌入第三方組件如地圖、支付、客服插件或?qū)崿F(xiàn)多頁(yè)面應(yīng)用通信時(shí)非常有用。基本用法// 發(fā)送方 (例如父頁(yè)面) const iframe document.getElementById(myIframe); const targetWindow iframe.contentWindow; const targetOrigin https://trusted-site.com; // 必須指定目標(biāo)源出于安全考慮 // 發(fā)送消息 targetWindow.postMessage({ type: USER_DATA, payload: userInfo }, targetOrigin); // 接收方 (例如 iframe 內(nèi)的頁(yè)面) window.addEventListener(message, (event) { // 重要?jiǎng)?wù)必驗(yàn)證消息來(lái)源 if (event.origin ! https://parent-site.com) { // 忽略來(lái)自未知源的消息 return; } console.log(收到消息:, event.data); // 處理消息... });關(guān)鍵點(diǎn)安全性postMessage的第一個(gè)參數(shù)targetOrigin和接收方的event.origin檢查至關(guān)重要可以防止惡意網(wǎng)站攔截或發(fā)送偽造消息。異步通信是異步的基于事件監(jiān)聽。結(jié)構(gòu)化克隆算法可以傳遞能夠被結(jié)構(gòu)化克隆算法處理的任何對(duì)象包括大多數(shù)原生類型、對(duì)象、數(shù)組但不能傳遞函數(shù)、DOM 元素等。3.2 修改document.domain同主域下的“捷徑”這是一個(gè)非常受限且逐漸被廢棄的方法。它只適用于一種特殊情況兩個(gè)頁(yè)面擁有相同的頂級(jí)域名和相同的二級(jí)域名只是子域名不同。例如a.example.com和b.example.com。原理通過(guò)將兩個(gè)頁(yè)面的document.domain都設(shè)置為example.com瀏覽器會(huì)認(rèn)為它們同源從而允許直接訪問(wèn)彼此的 DOM 和 Cookie。// 在 a.example.com 和 b.example.com 的頁(yè)面中都執(zhí)行 document.domain example.com;嚴(yán)重限制只能設(shè)置為當(dāng)前域或其父域。一旦設(shè)置無(wú)法再改回更具體的子域。端口號(hào)會(huì)被忽略如果端口不同仍可能有問(wèn)題。現(xiàn)代瀏覽器出于安全考慮對(duì)此方法的限制越來(lái)越多不推薦在新項(xiàng)目中使用。3.3 WebSocket不受同源策略限制的“特例”WebSocket 協(xié)議 (ws://或wss://) 在建立連接時(shí)使用的 HTTP 升級(jí)握手請(qǐng)求受同源策略約束。但是一旦連接建立后續(xù)通過(guò)該連接進(jìn)行的雙向數(shù)據(jù)傳輸不受同源策略限制。這意味著你可以通過(guò)一個(gè) WebSocket 連接與任何源的服務(wù)器進(jìn)行實(shí)時(shí)通信。不過(guò)服務(wù)器端仍然可以在握手階段通過(guò)檢查Origin頭來(lái)決定是否接受連接這是一種應(yīng)用層的安全控制。4. 跨域?qū)崙?zhàn)從開發(fā)到部署的完整鏈路理解了各種方案我們需要將其串聯(lián)到實(shí)際的工作流中。一個(gè)典型的前后端分離項(xiàng)目跨域處理會(huì)貫穿開發(fā)、測(cè)試、部署全流程。4.1 開發(fā)環(huán)境的最佳實(shí)踐在開發(fā)階段我們的核心訴求是高效、無(wú)阻塞地調(diào)試。推薦組合使用以下方案首選開發(fā)服務(wù)器代理配置 Vite/Webpack Dev Server 的代理。這是最干凈、最模擬生產(chǎn)環(huán)境的方式。前端代碼中直接使用相對(duì)路徑如/api/user或配置一個(gè)基礎(chǔ) URL由開發(fā)服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)到真正的后端地址。這樣做的好處是前端代碼無(wú)需關(guān)心環(huán)境差異與生產(chǎn)環(huán)境的調(diào)用方式保持一致。臨時(shí)禁用瀏覽器安全策略僅限本地這是一個(gè)極其不推薦但有時(shí)用于快速驗(yàn)證的臨時(shí)方法。絕對(duì)不要將其作為解決方案更不要指導(dǎo)用戶這樣做。Chrome通過(guò)命令行啟動(dòng)chrome.exe --disable-web-security --user-data-dirC:\TempChrome。這會(huì)關(guān)閉所有同源策略檢查非常危險(xiǎn)僅用于臨時(shí)測(cè)試。瀏覽器插件存在一些允許臨時(shí)禁用 CORS 的插件同樣只應(yīng)在完全可控的本地環(huán)境使用。重要警告禁用瀏覽器安全策略會(huì)讓你暴露在各種網(wǎng)絡(luò)攻擊風(fēng)險(xiǎn)下僅可作為最后手段的臨時(shí)測(cè)試且測(cè)試后應(yīng)立即關(guān)閉。在任何正式開發(fā)、測(cè)試或生產(chǎn)指導(dǎo)中都不應(yīng)提及此方法。后端開啟寬松 CORS用于開發(fā)讓后端同學(xué)在開發(fā)環(huán)境的代碼中配置允許來(lái)自本地前端開發(fā)服務(wù)器地址如http://localhost:3000的跨域請(qǐng)求。這需要后端配合是比代理更“正式”一點(diǎn)的開發(fā)環(huán)境方案。實(shí)操心得在團(tuán)隊(duì)中將開發(fā)服務(wù)器的代理配置寫入項(xiàng)目文檔或README.md是新成員快速上手的關(guān)鍵一步。確保vite.config.js或webpack.config.js中的代理配置清晰、準(zhǔn)確。4.2 生產(chǎn)環(huán)境的架構(gòu)設(shè)計(jì)生產(chǎn)環(huán)境中跨域問(wèn)題主要通過(guò)后端和基礎(chǔ)設(shè)施層面解決前端代碼應(yīng)保持“無(wú)感知”。標(biāo)準(zhǔn)方案后端配置 CORS這是最主流、最推薦的方式。后端服務(wù)在響應(yīng)中設(shè)置精確的Access-Control-Allow-Origin等頭部。例如允許你的前端域名https://www.myapp.com和https://admin.myapp.com。切勿在生產(chǎn)環(huán)境使用*除非是完全公開的、無(wú)需憑證的 API如公開的天氣 API。架構(gòu)方案API 網(wǎng)關(guān) / 反向代理在微服務(wù)或復(fù)雜架構(gòu)中通常會(huì)在前端和后端服務(wù)之間設(shè)立一個(gè) API 網(wǎng)關(guān)如 Kong, Apigee或使用 Nginx 作為反向代理。所有前端請(qǐng)求都發(fā)往同一個(gè)域名網(wǎng)關(guān)域名由網(wǎng)關(guān)負(fù)責(zé)路由到內(nèi)部各個(gè)微服務(wù)并在網(wǎng)關(guān)層面統(tǒng)一處理 CORS 策略、認(rèn)證、限流等。這樣前端完全不用處理跨域后端各服務(wù)也無(wú)需單獨(dú)配置 CORS。CDN 與靜態(tài)資源對(duì)于圖片、字體、樣式等靜態(tài)資源的跨域可能會(huì)遇到字體文件的 CORS 問(wèn)題font-face。通常的解決方案是在存放靜態(tài)資源的服務(wù)器如 OSS、S3、Nginx上配置 CORS 頭。使用 CDN 服務(wù)并在 CDN 配置中開啟 CORS 支持。對(duì)于字體文件除了 CORS 頭可能還需要設(shè)置Access-Control-Allow-Origin和正確的Content-Type。4.3 文件上傳與跨域的特殊處理文件上傳是一個(gè)常見的跨域難點(diǎn)因?yàn)橥ǔＩ婕癿ultipart/form-data格式和可能的大文件傳輸。方案一通過(guò)表單直接提交到目標(biāo)域名。這是最傳統(tǒng)的方式表單的action直接指向目標(biāo)服務(wù)器表單提交本身不受同源策略限制。但這種方式用戶體驗(yàn)差無(wú)法在前端做預(yù)覽、進(jìn)度提示等。方案二前端直傳 OSS推薦對(duì)于上傳到云存儲(chǔ)如阿里云 OSS、AWS S3的場(chǎng)景最佳實(shí)踐是前端直接從瀏覽器上傳到 OSS而不是經(jīng)過(guò)自己的應(yīng)用服務(wù)器中轉(zhuǎn)。流程通常是前端向自己的應(yīng)用服務(wù)器申請(qǐng)一個(gè)臨時(shí)的、有時(shí)效性的上傳憑證STS Token 或預(yù)簽名 URL。前端使用這個(gè)憑證直接調(diào)用 OSS 的 SDK 或使用表單直傳 API 將文件上傳到 OSS。OSS 服務(wù)需要配置允許前端頁(yè)面所在域名的 CORS。在 OSS 控制臺(tái)可以配置詳細(xì)的 CORS 規(guī)則允許PUT、POST等方法以及必要的頭信息。// 以阿里云 OSS 瀏覽器直傳為例簡(jiǎn)化 // 1. 從自己服務(wù)器獲取簽名和 policy const { signature, policy, ossHost, key } await getUploadTokenFromMyServer(); // 2. 構(gòu)建表單數(shù)據(jù) const formData new FormData(); formData.append(key, key); formData.append(policy, policy); formData.append(OSSAccessKeyId, your-temp-access-key-id); formData.append(signature, signature); formData.append(file, fileObject); // 文件對(duì)象 // 3. 直接 POST 到 OSS跨域請(qǐng)求OSS 已配置 CORS const response await fetch(ossHost, { method: POST, body: formData });方案三自己的服務(wù)器代理上傳。如果必須上傳到自己的服務(wù)器且服務(wù)器已正確配置 CORS允許Content-Type: multipart/form-data那么使用FormData配合fetch或axios上傳即可瀏覽器會(huì)自動(dòng)處理預(yù)檢請(qǐng)求。5. 深度排查當(dāng) CORS 依然報(bào)錯(cuò)時(shí)即使你認(rèn)為已經(jīng)正確配置了 CORS瀏覽器可能依然會(huì)拋出錯(cuò)誤。以下是一個(gè)系統(tǒng)性的排查清單幫助你定位問(wèn)題根源。5.1 預(yù)檢請(qǐng)求OPTIONS失敗這是最常見的問(wèn)題之一。癥狀是 Network 面板中能看到一個(gè)OPTIONS請(qǐng)求并且它返回了非 2xx 狀態(tài)碼如 404, 405, 500或者響應(yīng)頭中缺少必要的 CORS 頭。排查步驟檢查服務(wù)器是否響應(yīng) OPTIONS 方法很多后端框架的路由默認(rèn)只配置了GET,POST,PUT,DELETE漏掉了OPTIONS。你需要確保你的路由或全局中間件能正確處理OPTIONS請(qǐng)求并返回正確的 CORS 頭。檢查Access-Control-Allow-Methods確保它包含了實(shí)際請(qǐng)求所使用的 HTTP 方法如PUT,DELETE。檢查Access-Control-Allow-Headers確保它包含了前端請(qǐng)求中出現(xiàn)的所有自定義頭如Authorization,X-Custom-Header。像Content-Type為application/json時(shí)也需要將其加入允許的頭部列表。檢查Access-Control-Max-Age如果設(shè)置了這個(gè)頭瀏覽器會(huì)緩存預(yù)檢結(jié)果。在調(diào)試時(shí)可以暫時(shí)將其設(shè)置為0或移除以確保每次請(qǐng)求都發(fā)送預(yù)檢方便看到最新改動(dòng)。5.2 憑證Cookies與Access-Control-Allow-Origin沖突錯(cuò)誤現(xiàn)象前端設(shè)置了credentials: ‘include‘但服務(wù)器響應(yīng)頭Access-Control-Allow-Origin的值是通配符*。瀏覽器控制臺(tái)報(bào)錯(cuò)The value of the ‘Access-Control-Allow-Origin‘ header in the response must not be the wildcard ‘*‘ when the request‘s credentials mode is ‘include‘.解決方案服務(wù)器必須返回一個(gè)明確的、具體的源如https://www.myapp.com而不能是*。同時(shí)響應(yīng)頭中必須包含Access-Control-Allow-Credentials: true。5.3 響應(yīng)頭未暴露給前端錯(cuò)誤現(xiàn)象前端可以收到響應(yīng)但無(wú)法通過(guò)response.headers.get(‘My-Header‘)讀取某些自定義響應(yīng)頭。原因默認(rèn)情況下瀏覽器只將簡(jiǎn)單響應(yīng)頭Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma暴露給前端 JavaScript。其他自定義頭如Authorization,X-Pagination-Total需要服務(wù)器通過(guò)Access-Control-Expose-Headers頭顯式暴露。解決方案在服務(wù)器響應(yīng)頭中添加Access-Control-Expose-Headers: ‘Authorization, X-Pagination-Total‘。5.4 攜帶 Cookie 的請(qǐng)求Origin 檢查失敗錯(cuò)誤現(xiàn)象請(qǐng)求攜帶了 Cookie但服務(wù)器檢查Origin頭后發(fā)現(xiàn)不在白名單內(nèi)因此拒絕了請(qǐng)求。排查確保服務(wù)器端的 CORS 中間件邏輯正確。當(dāng)使用credentials: ‘include‘時(shí)前端的fetch請(qǐng)求會(huì)始終攜帶Origin頭。服務(wù)器的邏輯應(yīng)該是讀取req.headers.origin判斷其是否在允許的源列表中如果在則設(shè)置Access-Control-Allow-Origin為該具體的源值不能是*。5.5 使用工具進(jìn)行網(wǎng)絡(luò)分析開發(fā)者工具 (Network Panel) 是你的最佳朋友打開Preserve log保留日志防止頁(yè)面跳轉(zhuǎn)請(qǐng)求被清除。找到出錯(cuò)的請(qǐng)求點(diǎn)擊查看Headers標(biāo)簽。仔細(xì)對(duì)比「Request Headers」和「Response Headers」。Request Headers查看Origin頭是否正確發(fā)送。查看Access-Control-Request-Method和Access-Control-Request-Headers僅在預(yù)檢請(qǐng)求中出現(xiàn)。Response Headers這是排查重點(diǎn)。逐一核對(duì)Access-Control-Allow-Origin,Access-Control-Allow-Methods,Access-Control-Allow-Headers,Access-Control-Allow-Credentials,Access-Control-Expose-Headers是否存在且值正確。查看Response標(biāo)簽和Console標(biāo)簽中的完整錯(cuò)誤信息?？缬騿?wèn)題本質(zhì)上是前后端協(xié)同的協(xié)議問(wèn)題。前端需要知道如何發(fā)起合規(guī)的請(qǐng)求如設(shè)置credentials后端必須響應(yīng)以正確的許可頭。掌握這套“握手”規(guī)則并善用瀏覽器開發(fā)者工具進(jìn)行調(diào)試絕大多數(shù)跨域難題都能迎刃而解。記住安全是前提所有的解決方案都應(yīng)在同源策略的框架內(nèi)為合法的跨源通信開一扇窗而不是拆掉整面墻。