CORS Policy 完整解析：透過 HTTP Header 掌控跨域存取權限與資安防護

什麼是 CORS Policy？

當瀏覽器發現請求的來源網域與目標資源不同時，同源政策（SOP）會自動攔截回應。CORS 透過伺服器回應的 HTTP Header，明確授權哪些外部來源可合法存取資源，是 SOP 的官方延伸機制，而非繞過它。

核心 Header 為 Access-Control-Allow-Origin，指定允許存取的來源網域。搭配 Access-Control-Allow-Methods 限制 HTTP 動詞，以及 Access-Control-Allow-Headers 控制可攜帶的請求標頭。三者共同構成完整的 CORS 授權邊界。對於帶有 Cookie 或憑證的請求，還需額外設定 Access-Control-Allow-Credentials: true，且此時來源不得使用萬用字元 *。

Preflight 請求與資安風險

對於非簡單請求（如 PUT、DELETE 或含自訂 Header），瀏覽器會先發送 OPTIONS Preflight 請求，確認伺服器是否允許該操作，再發送實際請求。伺服器需正確回應 Access-Control-Max-Age 以快取 Preflight 結果，降低額外的網路延遲。

常見資安錯誤包括：將 Access-Control-Allow-Origin 設為 * 並同時允許憑證（瀏覽器會直接拒絕），或動態反射任意來源而未驗證白名單，導致惡意網站可跨域讀取敏感 API 回應。CORS 設定鬆散是常見的 API 資安漏洞來源之一。

Access-Control-Allow-Origin: https://trusted-app.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400

💡 重點整理

• 永不使用 * 作為生產環境的來源設定，應明確列出白名單網域。
• Preflight 是瀏覽器行為，無法被前端繞過，但惡意工具（如 curl）可忽略，CORS 無法取代後端授權驗證。
• 動態反射來源前必須比對白名單，防止任意網域取得授權回應。
• 憑證模式下來源必須精確指定，Allow-Credentials: true 與 * 無法並存。

CORS 是瀏覽器與伺服器之間的信任協議，正確設定能在開放 API 存取的同時守住資安邊界。最小授權原則是關鍵：只開放必要的來源、方法與標頭，其餘一律拒絕。

📚 參考文獻

1. MDN Web Docs — Cross-Origin Resource Sharing (CORS)：最完整的官方規範說明與 Header 參考文件。
2. WHATWG Fetch Standard — CORS Protocol：瀏覽器 Fetch 行為與 CORS 的底層規範定義。
3. PortSwigger Web Security — CORS vulnerabilities：涵蓋常見 CORS 錯誤設定的資安攻防分析。

⚠️ 本文內容基於撰寫時的最新資訊，實際應用時請參考

標籤