為什麼瀏覽器會阻止跨網域請求？
當你在開發前端應用時，是否曾經遇過「Access-Control-Allow-Origin」的錯誤訊息？這並非系統故障，而是瀏覽器為了保護使用者安全所實施的「同源政策（Same-Origin Policy, SOP）」機制。SOP 限制了來自不同來源（協定、網域名稱或連接埠不同）的網頁程式碼，無法直接讀取另一個來源的敏感資料。
同源政策與 CORS 的核心差異
同源政策是瀏覽器的預設行為，而 CORS（Cross-Origin Resource Sharing）則是為了在安全前提下，讓伺服器能主動授權特定外部來源存取資料的機制。透過 HTTP 標頭的交換，伺服器可以明確定義哪些來源是被允許的。
開發者小撇步：CORS 錯誤通常發生在瀏覽器端，而非伺服器端錯誤。即便後端 API 運作正常，若缺乏正確的 CORS 設定，瀏覽器仍會基於安全性攔截回應。
簡單請求與預檢請求的判斷標準
並非所有請求都需要經過複雜的 CORS 握手。根據 HTTP 方法與標頭的複雜度，瀏覽器會將請求分為「簡單請求」與「非簡單請求」。
| 請求類型 | 特徵 | 預檢請求（Preflight） |
|---|---|---|
| 簡單請求 | GET/POST，且僅使用標準標頭 | 不需要 |
| 非簡單請求 | 包含自定義標頭或 PUT/DELETE 方法 | 需要 (OPTIONS) |
預檢請求（Preflight Request）的運作機制
對於非簡單請求，瀏覽器會先發送一個 OPTIONS 請求到伺服器，詢問「我是否可以發送這個請求？」。伺服器收到後，會回傳允許的來源、方法與標頭。只有在預檢通過後，瀏覽器才會發送實際的請求。
常見的 CORS 設定錯誤
- Access-Control-Allow-Origin 設定為通配符（*）且允許認證資訊（Credentials）。
- 未正確處理 OPTIONS 請求，導致預檢失敗。
- 缺少必要的 Access-Control-Allow-Headers 設定。
- 將所有來源都開放，導致潛在的跨站攻擊風險。
如何正確設定 API 的 CORS 標頭
在伺服器端設定時，應遵循「最小權限原則」。明確指定允許的 Origin，而非使用星號。對於需要傳送 Cookie 的應用，務必將 Access-Control-Allow-Credentials 設定為 true，並確保 Origin 沒有被設為 *。
安全性警告：若您的 API 包含敏感使用者資料，切勿在生產環境中將 Access-Control-Allow-Origin 設定為 *，這將導致任何網站都能讀取您的 API 資料。
現代化 API 設計的安全性考量
除了 CORS，建議同步檢視其他安全性標頭，如 Content-Security-Policy (CSP) 與 X-Content-Type-Options。透過整合這些機制，能大幅降低 XSS 與跨站請求偽造的風險，確保 Web 應用程式的穩固與可靠。