跨來源資源共用 CORS 的安全配置策略：從瀏覽器機制到生產環境防護

跨域請求的隱形邊界：為什麼我們需要 CORS

當開發者首次遇到瀏覽器控制台顯示『Access to XMLHttpRequest at ... has been blocked by CORS policy』時，往往會感到挫折。這並非瀏覽器刻意阻礙開發，而是現代網路安全架構中的一道重要防線。CORS（Cross-Origin Resource Sharing）機制的核心在於，瀏覽器為了保護使用者資料，預設禁止網頁向不同網域發送請求，除非伺服器明確授權。

在分散式架構日益普及的今天，前後端分離開發已是主流，前端應用程式（如 React 或 Vue）經常需要呼叫位於不同網域的 API。若沒有 CORS 機制，惡意網站可以輕易地以使用者的身份向銀行或社群網站發送請求。因此，理解如何優雅且安全地處理跨域問題，是每一位 API 開發者必須具備的關鍵能力。

瀏覽器如何執行 CORS 檢查：機制與流程拆解

CORS 的運作並非單一的請求過程，瀏覽器會根據請求的複雜度，採取不同的驗證策略。簡單請求（Simple Request）通常指僅使用 GET、POST 或 HEAD 方法，且 Content-Type 僅限於 text/plain、application/x-www-form-urlencoded 或 multipart/form-data 的請求。

對於更複雜的請求，如包含自定義 Header 或使用 PUT、DELETE 方法，瀏覽器會先發送一個 OPTIONS 預檢請求（Preflight Request）。伺服器必須回應對應的 Header，告知瀏覽器是否允許該來源、該方法以及該標頭。若伺服器回應錯誤或未包含必要的 CORS Header，瀏覽器便會直接中斷後續的實際請求，確保資源不被非法存取。

預檢請求的隱形成本與效能影響

預檢請求雖然提升了安全性，但也增加了網路來回的延遲。若每個 API 呼叫都觸發一次預檢，將對系統效能產生負面影響。開發者應善用 Access-Control-Max-Age 標頭，讓瀏覽器快取預檢結果，從而減少不必要的 OPTIONS 請求。

常見的 CORS 配置誤區與安全風險

許多開發者為了快速解決錯誤，習慣將 Access-Control-Allow-Origin 設定為通配符『*』。這種做法在開發環境或許方便，但在生產環境中卻是極大的資安漏洞。一旦設定為『*』，意味著任何惡意網站都可以讀取該 API 的回應內容，這將導致敏感資料洩漏。

實務觀察： 避免使用反射機制（Reflection）直接將請求的 Origin Header 原封不動地回傳給 Access-Control-Allow-Origin。這同樣會導致安全性失效，因為它等於變相開放了所有來源的權限。

另一個常見誤區是忽略了 Access-Control-Allow-Credentials。若前端需要攜帶 Cookie 或認證資訊（如 Authorization Header），伺服器必須明確將此標頭設為 true，且 Origin 不能設為『*』。這兩者之間的衝突是許多開發者在實作驗證機制時最常遇到的瓶頸。

CORS 與 API 安全性的決策判斷表

情境	建議策略	風險等級
公開 API (Public API)	允許特定來源或使用嚴格的白名單	中
攜帶 Cookie 的請求	設定 Allow-Credentials 為 true，並指定具體 Origin	高
內部微服務溝通	不需 CORS，透過內網 Gateway 處理	低
開發環境測試	使用本地代理 (Proxy) 繞過限制	極低

實作策略：如何建立安全的跨域防護清單

為了確保 API 的 CORS 配置既能滿足功能需求，又能維持高度安全性，建議遵循以下操作步驟進行檢查與部署：

定義白名單： 在伺服器端維護一份明確的允許來源清單（Allowed Origins），拒絕任何不明請求。
動態判斷 Origin： 在處理請求時，檢查請求的 Origin Header 是否存在於白名單中，若符合則動態返回該 Origin。
限制方法與標頭： 僅允許 API 實際使用的 HTTP 方法（如 GET, POST）與必要的自定義標頭，禁止開放不必要的權限。
設定快取時效： 設定合理的 Access-Control-Max-Age，平衡效能與安全性。
分離錯誤處理： 確保 CORS 錯誤不會洩漏伺服器內部架構資訊，僅返回標準的 403 Forbidden。

進階場景：當 CORS 遇上 API Gateway 與負載平衡器

在大型系統中，CORS 的處理不應僅侷限於後端應用程式碼，更適合在 API Gateway 層面統一控管。將 CORS 邏輯移至 Gateway，可以確保所有微服務遵循一致的安全性原則，減少因開發人員疏忽而導致的配置漏洞。

當請求經過多層負載平衡器時，務必確認請求的 Host 與 Origin 資訊未被錯誤覆寫。若架構中包含多重代理，請確保 Forwarded Header 的正確傳遞，以利後端進行正確的來源判斷。這種架構上的解耦，不僅提升了系統的可維護性，也讓資安稽核變得更加透明與簡單。

延伸思考： 在現代前端框架中，使用 API Proxy（如 Vite 或 Webpack Dev Server 的 proxy 功能）在開發期間繞過 CORS 是常見作法，但請務必確保生產環境的 CORS 邏輯已正確實作，切勿依賴開發工具的繞過機制。

持續演進的安全觀念：Beyond CORS

隨著網路技術的演進，CORS 只是防禦跨站攻擊的一環。開發者還應配合 Content Security Policy (CSP) 與 SameSite Cookie 等機制，建立多層次的防禦體系。CORS 解決的是『誰可以存取 API』的問題，而 CSP 則能進一步限制『網頁可以載入哪些資源』，兩者相輔相成。

最後，定期審查 API 的 CORS 設定檔，尤其是在新增服務或變更部署環境時。隨著 API 版本迭代，過時的跨域設定往往成為隱形的攻擊面。保持對 HTTP 協定細節的敏感度，並持續監控異常的跨域請求模式，是確保服務長期穩定的必要工程投入。