CORS 是什麼？

為什麼CORS 很重要？

同源政策(Same-Origin Policy, SOP)

1. 通訊協定（Protocol） 相同（例如都是 https）

2. 網域（Domain） 相同（例如都是 example.com）

3. 連接埠（Port） 相同（例如都是 80 或 443）

COR 如何運作？

1. 瀏覽器在請求中新增一個來源標頭，其中包含有關當前來源的協定、主機和連接埠的資訊

2. 伺服器檢查當前的來源標頭並使用請求的資料和 Access-Control-Allow-Origin 標頭進行回應

3. 瀏覽器看到存取控制請求標頭並然後與用戶端應用程式分享返回的資料

• 前後端分離架構（SPA + API）時，前端呼叫自家後端 API

• 使用CDN、第三方API

• 微服務（Microservices）之間的資源共享

• 企業內部開發與測試環境

跨來源資源共用案例

Access-Control-Allow-Origin: https://news.example.com

CORS 的運作機制

複雜的跨來源請求

• GET、POST 或 HEAD 之外的方法

• Accept-Language、Accept 或 Content-Language 之外的標頭

• multipart/form-data、application/x-www-form-urlencoded 或 text/plain 之外的 Content-Type 標頭

簡單請求（Simple Request）

sequenceDiagram
    autonumber
    participant FE as Frontend (Browser)
    participant BE as Backend Server

    Note over FE: User triggers cross-origin request<br/>(e.g., GET /api/user)
    FE->>BE: HTTP GET (with automatic Header -> Origin: https://frontend.com)
    
    Note over BE: Server processes request and checks Origin
    BE-->>FE: HTTP 200 OK<br/>with Access-Control-Allow-Origin: https://frontend.com
    
    alt Headers Match
        Note over FE: Browser validation passed.<br/>Data passed to JavaScript.
    else Headers Mismatch (or Missing)
        Note over FE: Browser blocks the response data<br/>and throws CORS Error in Console.
    end

• 前端發起請求： 使用者在網頁上觸發跨域動作（例如透過 GET 獲取使用者資料），瀏覽器會在 HTTP 請求標頭（Header）中，自動加上發起網域的標記 Origin: https://frontend.com。

• 後端伺服器處理： 伺服器接收到請求後照常處理，並在回應（Response）中加入 CORS 相關標頭，告訴瀏覽器它允許哪些網域存取，例如：Access-Control-Allow-Origin: https://frontend.com。

• 瀏覽器最終檢查（分歧點）：
• 若標頭吻合（Headers Match）： 瀏覽器確認後端回傳的允許網域包含前端的 Origin，於是通過驗證，將資料交給前端的 JavaScript 程式碼。
• 若標頭不吻合（Headers Mismatch）： 如果後端沒有設定、或者設定的網域不匹配，瀏覽器就會在接收端硬生生將資料攔截，前端程式拿不到資料，並在控制台（Console）噴出 CORS 錯誤。

預檢請求（Preflight (OPTIONS) Request））

sequenceDiagram
    autonumber
    participant FE as Frontend (Browser)
    participant BE as Backend Server

    Note over FE: Triggers Non-Simple Request<br/>(e.g., PUT /api/user with JSON payload)
    
    Note over FE, BE: [Phase 1: Preflight Request]
    FE->>BE: HTTP OPTIONS (Asks if Method: PUT & Custom Headers are allowed)
    Note over BE: Server validates if the Origin<br/>is allowed for this operation
    BE-->>FE: HTTP 200 OK<br/>with Access-Control-Allow-Methods/Headers/Origin
    
    Note over FE, BE: [Phase 2: Actual Request]
    alt Preflight Allowed
        FE->>BE: HTTP PUT (Sends the actual data and request)
        BE-->>FE: HTTP 200 OK (Returns actual data)
        Note over FE: Frontend successfully receives data
    else Preflight Denied
        Note over FE: Browser aborts the actual request,<br/>returns CORS Error immediately.
    end

• 【階段一：預檢請求 (Preflight Request)】
1. 發送探路請求： 瀏覽器不會直接送出真正的資料，而是先自動發送一個 HTTP OPTIONS 請求給伺服器，詢問：「我等一下想用 PUT 方法和某些自訂標頭送資料，你接受嗎？」
2. 伺服器安全審查： 伺服器檢查這個來源與操作是否在允許的白名單內，若允許，則回傳 200 OK，並帶上允許的方法與標頭限制（Access-Control-Allow-Methods/Headers/Origin）。

• 【階段二：正式請求 (Actual Request)】（分歧點）
• 預檢通過（Preflight Allowed）： 瀏覽器確認伺服器允許該操作，接著才會發送「真正的」PUT 請求與 JSON 資料，伺服器處理完後回傳正式資料，前端順利接收。
• 預檢拒絕（Preflight Denied）： 如果第一階段伺服器就說不允許，瀏覽器會直接中斷後續動作，完全不會發送真正的 PUT 請求，並立刻回報 CORS 錯誤。這能有效保護伺服器不被執行未授權的敏感操作。

CORS 的 Cookies 操作

sequenceDiagram
    autonumber
    participant FE as Frontend (Browser)
    participant BE as Backend Server

    Note over FE: Step 0: SameSite Check
    
    alt Cookie is Lax or Strict
        Note over FE: Browser blocks Cookie
    else Cookie is None and Secure
        alt withCredentials is FALSE
            FE->>BE: HTTP Request (NO Cookies)
            BE-->>FE: HTTP 200 OK Response
        else withCredentials is TRUE
            FE->>BE: HTTP Request (WITH Cookies)
            BE-->>FE: HTTP 200 OK Response
            Note over FE: Browser Security Check
            alt Missing Credentials Header
                FE->>FE: CORS Error (Missing Header)
            else Origin is Wildcard
                FE->>FE: CORS Error (Wildcard Not Allowed)
            else Origin Matches Exactly
                FE->>FE: Validation Passed
            end
            Note over FE: JS Reads Session Data
        end
    end

Step 0：瀏覽器底層 SameSite 阻擋檢查

• 阻擋情況： 若 Cookie 被設定為 SameSite=Lax（現代瀏覽器預設值）或 Strict，且該跨域請求是由前端 AJAX（如 fetch 或 axios）觸發，瀏覽器在此步驟會直接扣留 Cookie，不予發送。

• 放行條件： 後端在核發 Cookie 時，必須明確宣告為 SameSite=None; Secure，該 Cookie 才能參與後續的跨域傳輸。

分支 A：前端 withCredentials 為 FALSE（Default）

• Step 1. (Frontend -> Backend Server)： 前端未在程式碼中開啟憑證傳輸（如 Fetch 未設定 credentials: 'include'）。瀏覽器在發送前自動拔除 Cookie，發送不帶憑證的匿名請求。

• Step 2. (Backend Server -> Frontend)： 後端伺服器接收請求後，由於未收到 Cookie，將其視為匿名訪客處理，並正常回傳 200 OK 響應。前端雖拿到資料，但無法執行涉及會員身分的操作。

分支 B：前端 withCredentials 為 TRUE

• Step 3. (Frontend -> Backend Server)： 前端明確開啟允許憑證設定（如 Axios 設定 withCredentials: true）。瀏覽器允許帶著該後端網域的 Cookie 跨域發送請求。

• Step 4. (Backend Server -> Frontend)： 後端伺服器成功讀取 Cookie 中的身分驗證資訊，依據該會員權限處理私密資料（如個人訂單），並回傳 200 OK 響應給瀏覽器。

瀏覽器的安全審查與分歧

• Step 6. (Frontend -> Frontend) [觸發關卡 A 失敗 —— 缺少 Credentials 標頭]： 瀏覽器檢查後端回傳的 Response Header，發現缺少 Access-Control-Allow-Credentials: true。
• 結果： 瀏覽器判定此跨域存取不安全，立刻觸發內部攔截機制，將整份回傳資料銷毀。前端 JavaScript 報錯且無法讀取內容。

• Step 6. (Frontend -> Frontend) [觸發關卡 B 失敗 —— Origin 為萬用字元 ]： 伺服器雖設定了 Credentials: true，但後端的 Access-Control-Allow-Origin 設定為萬用字元 。
• 結果： 瀏覽器判定此設定具備安全漏洞（任何惡意網站皆能利用此管道配合 withCredentials 讀取隱私資料）。在網頁安全規範中，「憑證傳輸」與「萬用字元（*）」絕對互斥，瀏覽器直接攔截回應並拋出 CORS 錯誤。

• Step 7. (Frontend -> Frontend) [兩道安全關卡皆通過 —— Origin 精準匹配]： 後端伺服器同時宣告允許憑證（true），且其 Access-Control-Allow-Origin 明確指定了與前端完全吻合的具體網域（如 https://frontend.com）。
• 結果： 瀏覽器安全審查通過，放行回應資料。

• Step 8. (最終結果)： 前端 JavaScript 順利讀取到帶有身分驗證的私密資料，跨域 Cookie 操作成功。

CORS 和 JSONP 的區別

JSONP 的核心運作機制

• 前端發起： 在 HTML 中動態插入 <script src="https://api.com/data?callback=handleResponse"></script>。

• 後端回應： 伺服器不能回傳純 JSON，必須回傳一個 JavaScript 函數呼叫，並將 JSON 資料當作參數傳入，例如：handleResponse({"status": "success"})。

• 瀏覽器執行： 瀏覽器下載該腳本後立刻執行，前端預先寫好的 handleResponse 函式隨即被觸發，藉此撈到資料。

JSONP 的缺點

• 僅支援 GET 方法： 由於本質是利用 <script src="..."> 載入外部檔案，其 src 屬性無法攜帶其他 HTTP 方法的資料，因此只能使用 GET。這導致前端完全無法使用 POST、PUT 或 DELETE 等方法來變更後端狀態。

• 資料格式受限： 傳輸的資料必須是 JSON 格式。

• 安全性低（XSS 攻擊風險）： JSONP 不如跨來源資源共用 (CORS) 安全，因為提供的資料安全與否全憑外部網域的可信度。使用 JSONP 等同於無條件執行外部網域回傳的任何 JavaScript 程式碼。如果該外部網域遭到駭客入侵、或該網域本身就不可信，駭客就能輕易在網頁上執行惡意腳本，偷走使用者的 Cookie 或機密資料。

• 錯誤處理極其困難： 因為不是正式的 AJAX 請求，當後端發生 404 Not Found 或 500 Internal Server Error 時，<script> 標籤只會靜默失敗（或者觸發全域的 onerror），前端難以精準捕捉到 HTTP 狀態碼來做對應的防錯處理。

現代的替代方案：CORS

參考

• MDN Web Docs跨來源資源共享（CORS） - HTTP | MDN
  

  跨來源資源共享（CORS） - HTTP | MDN

  跨來源資源共享（CORS）是一種基於 HTTP 標頭的機制，允許伺服器指示瀏覽器允許從除其自身以外的任何來源（域名、協定或通訊埠）加載資源。CORS 還依賴於瀏覽器向承載跨來源資源的伺服器發出「預檢」請求，以檢查伺服器是否允許實際請求。在預檢請求中，瀏覽器會發送標頭，指示將在實際請求中使用的 HTTP 方法和標頭。

  MDN Web Docs

• vocusCORS 是什麼？前後端工程師必知的跨網域資源共享
  

  CORS 是什麼？前後端工程師必知的跨網域資源共享

  說明 CORS 的演進、角色分工、Simple Request 與 Preflight (OPTIONS) Request 的差異，並著重探討 Cookies 在 CORS 環境下的複雜設定與常見陷阱。

  vocus

• Amazon Web Services, Inc.什麼是 CORS？- 跨來源資源共用說明 - AWS

  什麼是 CORS？- 跨來源資源共用說明 - AWS

  了解什麼是 CORS，以及如何在 AWS 使用跨來源資源共用。

  Amazon Web Services, Inc.