跳到主要內容

跨來源存取腳本（CORS）深度解析：配置風險、攻擊面擴大與資料洩漏防範

作者：

CORS 是瀏覽器的跨來源資源共享機制，設計目的是功能性開放，而非安全防線。一旦配置失當，將直接成為攻擊者的突破口。

CORS 的運作原理與配置風險

瀏覽器的同源政策（Same-Origin Policy）預設封鎖跨來源請求。CORS 透過 HTTP 回應標頭，允許伺服器主動宣告哪些來源可存取資源。其中最危險的配置是 Access-Control-Allow-Origin: *，代表任何來源皆可讀取回應內容。若同時搭配 Access-Control-Allow-Credentials: true，瀏覽器會拒絕此組合，但部分開發者為繞過限制，改用動態反射來源（將請求的 Origin 直接回寫至回應標頭），這才是真正高危的配置模式。攻擊者一旦發現此漏洞，即可透過惡意網頁向目標 API 發送帶 Cookie 的跨來源請求，竊取敏感資料。

攻擊面擴大與資料洩漏情境

CORS 配置不當主要引發兩類威脅。第一是資料洩漏：攻擊者控制的頁面可直接讀取 API 回應，包含帳號資訊、Token 或私人資料。第二是CSRF 攻擊面擴大：傳統 CSRF 無法讀取回應，但錯誤的 CORS 配置使攻擊者能完整擷取結果，大幅提升攻擊價值。常見高風險場景包括：內部 API 對任意來源開放、預檢請求（Preflight）被錯誤快取，以及 null 來源被信任（可透過沙箱 iframe 偽造）。這些問題根源在於開發者將 CORS 誤解為安全機制，實際上它只是存取控制的宣告層。

# 危險配置（動態反射來源 + 允許憑證）
Access-Control-Allow-Origin: https://attacker.com  ← 直接反射請求來源
Access-Control-Allow-Credentials: true

# 安全配置（明確白名單）
Access-Control-Allow-Origin: https://trusted.example.com
Access-Control-Allow-Credentials: true

💡 重點整理

  • 白名單嚴格化：Allow-Origin 必須使用靜態明確清單，禁止動態反射任意來源。
  • 避免信任 null 來源：Origin: null 可被沙箱 iframe 偽造，絕不列入白名單。
  • 最小化暴露範圍：僅對需跨來源存取的端點啟用 CORS，內部 API 應完全封閉。
  • CORS 不能取代驗證：仍需搭配 Token 驗證與 CSRF 防護，CORS 本身無法阻擋偽造請求。

CORS 配置錯誤是常見卻嚴重的安全漏洞。正確的白名單管理與最小權限原則，是防範跨來源攻擊的唯一有效手段。

📚 參考文獻

  1. MDN Web Docs — Cross-Origin Resource Sharing (CORS)：最完整的 CORS 機制官方說明與標頭參考。
  2. PortSwigger Web Security — CORS vulnerabilities：涵蓋動態來源反射、null 來源等實際攻擊情境解析。
  3. WHATWG Fetch Standard — CORS Protocol：CORS 的底層規範，
Labels:

留言

張貼留言