跳至主要內容

什麼是 CORS？從安全性角度為初學者解說

· 6 分鐘閱讀
ひかり

説明 Web 瀏覽器的安全功能 CORS (Cross-Origin Resource Sharing)，涵蓋「為什麼需要」和「有什麼風險」，為初學者量身打造的解説。正確理解 CORS 能夠實現安全的 Web 開發。

CORS 出現的背景：同源政策 (Same-Origin Policy)​

在 1990 年代初期，JavaScript 被引入瀏覽器時，Web 安全的概念幾乎不存在。當時，惡意網站可以自由存取其他網站的資料，容易導致工作階段劫持 (Session Hijacking) 和資料竊取。

為了解決這個問題，引入了一項稱為同源政策 (Same-Origin Policy) 的限制。這是一個簡單而強大的規則：「從網頁加載的 JavaScript 無法存取該網頁不同源的資料」。

例如，從 https://www.example.com 加載的 JavaScript 無法存取 https://www.bank.com 的資料。這樣，即使使用者登入銀行網站後訪問惡意網站，銀行資訊也不會被盜取。

什麼是源 (Origin)​

源 (Origin) 由以下三個要素決定：

  • 協議 (Protocol)：http:// 或 https://
  • 主機 (Host/網域)：example.com 或 api.example.com
  • 連接埠 (Port)：80 或 8080

例如，

URL協議主機連接埠源
https://www.example.com/pageHTTPSwww.example.com443 (預設)https://www.example.com
https://api.example.com/dataHTTPSapi.example.com443 (預設)https://api.example.com

由於主機不同，它們被視為不同的源。

同源政策防止的事項​

JavaScript 的 XHR (XMLHttpRequest) 或 Fetch API 對不同源的請求受到限制。

例：evil.com 上的惡意指令碼

fetch('https://bank.example.com/api/transfer', {
  method: 'POST',
  body: JSON.stringify({ amount: 1000000 })
});

沒有同源政策的話，惡意網站 (evil.com) 的 JavaScript 可以在使用者登入銀行網站的狀態下發送轉帳請求。防止這種情況就是同源政策的目的。

為什麼需要 CORS​

然而，現代 Web 開發經常涉及多個源的協作。

  • 前端：https://www.example.com
  • API 伺服器：https://api.example.com
  • CDN / 靜態文件：https://cdn.example.com

這些是由同一公司營運的正當通訊。但如果受到同源政策限制，應用程式就無法運作。

這時候 CORS (Cross-Origin Resource Sharing) 就派上用場了。

什麼是 CORS：明確允許存取​

CORS 是伺服器明確聲明「允許來自此源的請求」的機制。

伺服器只需返回以下回應標頭，瀏覽器就會放寬限制。

Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization

除非伺服器表示「允許」，否則瀏覽器不會將請求結果傳回 JavaScript。這樣既能實現跨源存取，又能保持安全性。

CORS 的安全風險：常見的設定錯誤​

雖然 CORS 很便利，但設定不當會造成安全漏洞。

錯誤：允許所有源​

Access-Control-Allow-Origin: *

這表示「世界上任何人都可以存取此伺服器」。

// https://evil.com 的 JavaScript
fetch('https://api.example.com/user/profile')
  .then(r => r.json())
  .then(data => {
    // 竊取使用者個人資料的處理
    console.log(data);
  });

對於包含認證憑證（如 Cookie）的請求特別危險，使用者在登入 api.example.com 後訪問 evil.com 時，個人資訊可能被盜取。

半危險：包含 Cookie 時禁止使用 *​

fetch('https://api.example.com/user/profile', {
  credentials: 'include'  // 包含 Cookie
})

包含認證資訊時，不能使用 Access-Control-Allow-Origin: *。必須明確指定特定的源。

Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true

錯誤：直接允許使用者指定的 URL​

// 危險的實現範例（伺服器端）
const origin = request.headers.get('Origin');
response.headers.set('Access-Control-Allow-Origin', origin);  // 原樣返回！

這樣做會允許來自 https://evil.com 的請求，回應會帶有 Access-Control-Allow-Origin: https://evil.com，容易被濫用。

正確做法是準備白名單，只允許列表中的源。

const allowedOrigins = [
  'https://www.example.com',
  'https://admin.example.com'
];

if (allowedOrigins.includes(origin)) {
  response.headers.set('Access-Control-Allow-Origin', origin);
}

錯誤：允許所有標頭​

Access-Control-Allow-Headers: *

這表示「接受任何標頭」，允許透過自訂標頭注入惡意資料的攻擊。

只列出必要的標頭。

Access-Control-Allow-Headers: Content-Type, Authorization

CORS 預檢請求：瀏覽器的事前確認​

對於簡單請求以外的請求（GET、HEAD、POST），瀏覽器會自動發送 OPTIONS 方法的請求來確認「這樣可以嗎？」這被稱為預檢請求 (Preflight Request)。

1. JavaScript 嘗試發送 PUT 請求

2. 瀏覽器自動發送 OPTIONS 預檢請求
    OPTIONS /api/resource HTTP/1.1
    Origin: https://www.example.com
    Access-Control-Request-Method: PUT
    Access-Control-Request-Headers: Content-Type

3. 伺服器回應「OK」
    HTTP 200 OK
    Access-Control-Allow-Origin: https://www.example.com
    Access-Control-Allow-Methods: PUT
    Access-Control-Allow-Headers: Content-Type

4. 瀏覽器發送實際的 PUT 請求

如果伺服器不支援 OPTIONS 方法，預檢就會失敗，實際請求也不會被發送。

要點：

  • 在白名單中明確指定允許的源
  • 使用 credentials: true 處理包含 Cookie 認證的請求
  • 只允許必要的方法和標頭
  • OPTIONS 預檢請求

常見疑問​

Q. 遇到 CORS 錯誤。可以允許所有源來解決嗎？​

A： 不可以。可能會暫時有效，但在生產環境中允許 * 是安全風險。需要重新檢查伺服器端設定或重新設計 API。

Q. 想在本地開發時存取不同連接埠的源。可以嗎？​

A： 在本地開發環境中只停用 CORS 是可以的。

Q. 從行動應用程式呼叫 API 時，CORS 有影響嗎？​

A： CORS 是瀏覽器的安全功能，所以對行動應用程式沒有影響。取而代之，需要使用 API 金鑰或 OAuth 實作認證和授權。

總結​

重點說明
CORS 的目的在保持瀏覽器安全性的同時允許跨源存取
危險的設定對需要認證的 API 使用 Access-Control-Allow-Origin: *
正確的設定在白名單中明確指定允許的源
包含 Cookie 時必須指定 Access-Control-Allow-Credentials: true 和具體的源
預檢PUT/DELETE 等複雜請求需要瀏覽器用 OPTIONS 進行事前確認

CORS 不只是「導致錯誤的原因」，而是 Web 安全的重要機制。設定錯誤可能導致安全事故，因此需要謹慎處理。

參考資料​

評論

載入中...

發表評論

★★★★★