跳至主要內容
>_ITDITD網站資安平台

名詞解釋

#CORS#漏洞#Web

CORS 是什麼 — 原理，以及設定錯誤（CORS misconfiguration）會引發什麼

CORS（跨來源資源共用）是瀏覽器用來控制「某個網站的 JavaScript 能否讀取另一個來源的 API 回應」的機制。如果把設定放得太寬，出現「CORS 設定錯誤」，第三方網站就可能讀取到已登入使用者的資料。本文從防禦視角講解它的原理，以及安全的設定方法（白名單、不要反射 Origin、不要把 * 和認證資訊同時使用）。

發布於 2026-06-11 更新於 2026-06-11 閱讀時間 1 分鐘

「給 API 加上 Access-Control-Allow-Origin 之後就能用了，但這樣安全嗎？」——CORS 並不是「加上就 OK」，關鍵在於把許可的對象收緊。本文講解它的原理和安全的設定方法（不會寫出攻擊步驟）。

先講原理

瀏覽器有一條同源政策：其他來源的 JS 不能擅自讀取其他網站的回應。CORS 就是用來把這條規則的例外只對伺服器明確許可的對象打開的機制。

回應標頭含義
Access-Control-Allow-Origin允許哪個來源讀取回應
Access-Control-Allow-Credentials是否允許帶 Cookie 等認證資訊的通訊
Access-Control-Allow-Methods / -Headers允許的 HTTP 方法/標頭

關鍵在於，CORS 是屬於「放寬限制」那一側的機制。放寬的方式一旦出錯，本不該被讀取的資料就會被第三方讀到。

哪些設定是危險的

危險的設定（容易犯）

  • 把請求的 Origin 原樣反射回去並予以許可
  • Access-Control-Allow-Origin: * ＋ 同時允許認證資訊
  • 把不必要的 API 也大範圍地對其他來源開放

安全的設定

  • 白名單（只放可信任的固定來源）
  • 其他一律預設拒絕
  • 帶認證資訊時不用 *，而指定具體的來源
攻擊者網站的 JS 向你的 API 發起請求（使用者處於登入狀態）
↓ 伺服器不加判斷地許可了 Origin（設定錯誤）
瀏覽器允許讀取回應＝個人資訊/權杖被交到攻擊者網站手裡
設定太寬時，攻擊者網站的 JS 就能借用使用者的登入狀態讀取到 API 的回應。

安全設定的基本原則

1

採用白名單方式（最重要）

只許可事先確定的可信任的來源，其他一律拒絕（預設拒絕）。不要「先全部許可了再說」。
2

不要不加判斷地反射 Origin

不要把請求裡的 Origin 原樣 echo 到 Access-Control-Allow-Origin。只有與白名單比對一致時才回傳。
3

帶認證資訊時不要用 *

帶 Cookie 等的通訊中，不要把 Access-Control-Allow-Origin: * 與 Allow-Credentials: true 同時使用。要指定具體的來源。
4

把開放範圍降到最小

只把確實需要對其他來源公開的端點作為對象。不要大範圍開放。設定可以用安全回應標頭診斷等來確認。

本站的觀點：CORS 不是「防守」，而是「放寬方式」。要收緊放寬的對象

一個常見的誤解是「加上 CORS 標頭就安全了」。恰恰相反，CORS 是屬於「放寬」瀏覽器限制那一側的機制。所以安全的訣竅與其說是「怎麼加」，不如說是「把對誰、開放到什麼程度收到最小」。本站建議把可以被外部讀取的資料和不可以的資料區分開，採取預設拒絕、只用白名單打開例外的方針。另外，讓「回應會被讀取」這一前提整個崩塌的 XSS，以及瞄準狀態變更的 CSRF 是另一類漏洞，所以單靠 CORS 並不能守住全部。

延伸閱讀

FAQ

QCORS 是做什麼用的機制？
A

瀏覽器有一條「同源政策」：另一個來源（網站）的 JavaScript 不能擅自讀取其他網站的回應。CORS（Cross-Origin Resource Sharing）就是用來把這條規則的例外「只對伺服器明確許可的對象」打開的機制。它透過 Access-Control-Allow-Origin 等回應標頭，宣告允許哪些來源讀取回應。

QCORS 設定錯誤會引發什麼？
A

如果許可放得太寬，攻擊者網站的 JavaScript 就可能讀取到使用者已登入的 API 回應。典型例子是：把請求的 Origin 原樣反射回去並予以許可，或者把 Access-Control-Allow-Origin 設為 * 的同時還允許認證資訊（Cookie 等）。結果就是個人資訊或權杖可能被交到第三方網站手裡。

Q安全設定的基本原則是什麼？
A

就是「白名單方式」。只許可事先確定的、可信任的來源，其他一律拒絕（預設拒絕）。不要不加判斷地反射請求裡的 Origin。在帶認證資訊的通訊中，Access-Control-Allow-Origin 不要用 *，而要指定具體的來源。最根本的是，只把確實需要對其他來源公開的端點作為對象。