在網頁開發中，跨來源資源共用（CORS）政策是保障瀏覽器安全的重要機制。不論是前端開發人員、後端開發人員、API 平台開發人員，還是運維工程師，都需要準確評估瀏覽器程式碼能否成功讀取特定的回應，或者確認 OPTIONS 預檢請求的回應是否已批准後續的方法及請求標頭。
「CORS 檢查器」是一個在瀏覽器本地運作的輔助工具，能根據你提供的 HTTP 回應標頭以及請求細節，模擬並解析瀏覽器的 CORS 判定結果。
運作原理與輸入參數
此工具透過比對你輸入的 HTTP 回應標頭與預期的請求屬性，分析瀏覽器在實際執行請求時的准允狀態。使用者需要提供以下幾項關鍵資訊：
- 檢查回應：可選擇「實際回應」或「預檢回應」。
- HTTP 回應標頭：貼上完整的 HTTP 回應標頭。若檢查預檢回應，請務必同時貼上 HTTP 狀態行。輸入上限為 200,000 個字元。若輸入留空，會顯示「在檢查之前貼上 HTTP 回應標頭。」；若超出限制，則會提示「此回應異常地長，請限制在
‹max›個字元內。」。若格式有誤，會觸發「第‹line›行不是有效的 HTTP 標頭或狀態行。」或「第‹line›行包含無效的 HTTP 標頭名稱。」等錯誤。 - 請求來源：輸入發起請求的來源（Origin），格式必須僅包含通訊協定、主機及可選連接埠（例如
https://app.example.com），不允許包含 URL 路徑、查詢參數或認證資訊。輸入不合規時會顯示「請輸入只包含通訊協定、主機及可選連接埠的來源，例如 https://app.example.com。」。 - 請求的方法：輸入預期的 HTTP 方法。若輸入無效 token，會顯示「請輸入有效的 HTTP 方法 token。」；若輸入瀏覽器禁用的方法，則會提示「瀏覽器不允許在 fetch 請求中使用
‹method›方法。」。 - 請求的標頭名稱：對應
Access-Control-Request-Headers，多個標頭名稱可用逗號或換行分隔。若名稱不合法，會顯示「“‹header›”不是有效的 HTTP 請求標頭名稱。」。 - 包含認證資料：切換開關，以標示請求是否包含 Cookie 或 HTTP 認證資訊。
瀏覽器判定結果與解析
當你輸入資料並點擊「檢查 CORS」後，工具會輸出「瀏覽器判定」及「已解析的 Access-Control 欄位」。判定狀態包括：
- 貼上回應以檢查其 CORS 政策。（初始狀態）
- 輸入回應及請求資料，然後檢查 CORS 政策。（未輸入完整資料時）
- 已貼上的 CORS 回應允許此請求。
- 已貼上的 CORS 回應封鎖此請求。
- 標頭通過，但預檢狀態未知。
來源與認證判定依據
- 完全匹配：當
Access-Control-Allow-Origin與請求來源一致時，顯示「Access-Control-Allow-Origin 與‹origin›完全匹配。」。 - 萬用字元：若允許任何來源，顯示「Access-Control-Allow-Origin 允許任何來源發出此請求。」。
- 缺失或不匹配：若無此標頭，顯示「缺少 Access-Control-Allow-Origin。」；若值不符，顯示「Access-Control-Allow-Origin 是
‹actual›，而非‹expected›。」；若值無效（例如包含多個值或以逗號分隔），則顯示「Access-Control-Allow-Origin 的值無效：‹value›。」。 - 認證限制：若啟用認證，
Access-Control-Allow-Origin不能為*，否則判定失敗並提示「包含認證資料時，Access-Control-Allow-Origin 不可設為 *。」。同時，回應必須明確包含Access-Control-Allow-Credentials: true，否則提示「包含認證資料的請求需要 Access-Control-Allow-Credentials: true。」。若未啟用認證，則提示「請求不包含認證資料，因此 Access-Control-Allow-Credentials 不會影響此判定。」。
預檢請求的特殊規則
在處理預檢回應（Preflight Response）時，瀏覽器對 HTTP 狀態碼、請求方法及自訂標頭有嚴格的審查機制：
- 狀態碼檢查：預檢請求必須返回成功的 2xx 狀態碼。若狀態碼正確，顯示「預檢狀態
‹status›成功。」；若非 2xx，顯示「預檢狀態‹status›不是成功的 2xx 狀態。」；若未貼上狀態行，則顯示「未貼上 HTTP 狀態行，因此無法檢查所需的 2xx 預檢狀態。」，此時預檢狀態會被判定為「未知」。 - 方法許可：若方法在安全清單內（如簡單的 GET、POST），顯示「
‹method›是 CORS 安全清單內的方法，毋須列於 Access-Control-Allow-Methods。」。若非安全清單方法，則需在標頭中明確允許，通過時顯示「預檢允許‹method›。」，否則顯示「Access-Control-Allow-Methods 不允許‹method›。」。 - 標頭許可：若無自訂標頭，顯示「沒有請求標頭名稱需要預檢批准。」。若有自訂標頭且獲授權，顯示「預檢允許請求的標頭名稱：
‹headers›。」。 - 萬用字元與 Authorization 的例外：在不包含認證資料時，
Access-Control-Allow-Headers: *可以涵蓋大部分標頭，顯示「如請求不包含認證資料，Access-Control-Allow-Headers: * 會涵蓋以下名稱：‹headers›。」。然而，Authorization標頭屬於特例，即使有*萬用字元，亦必須在Access-Control-Allow-Headers中明確寫出，否則會觸發「必須明確列出 Authorization；Access-Control-Allow-Headers: * 並不涵蓋它。」的錯誤。若不允許其他標頭，則顯示「Access-Control-Allow-Headers 不允許：‹headers›。」。
本地處理與隱私說明
本工具的解析與判定程序完全在你的瀏覽器內執行。你的標頭及請求資料只會留在瀏覽器內，BroBroGo 不會上載或儲存任何內容。
需要注意的是，此工具僅按瀏覽器 CORS 規則檢查一份已貼上的回應，不會連線至伺服器，亦不能證明實際請求、重新導向、緩存或擴充程式的行為完全相同。它不會讀取外部 URL、設定 Cookie、檢查 DNS/TLS，亦無法修改你的伺服器設定。
常見問題
我應該貼上實際回應還是預檢回應？
如要檢查瀏覽器程式碼能否讀取回應，請使用實際回應。如要檢查 OPTIONS 回應有否批准之後使用的方法及請求標頭名稱，請使用預檢回應。
為甚麼使用認證資料時萬用字元可能無效？
如請求包含 cookie 或 HTTP 認證，允許的來源必須與請求來源完全相符。允許方法及標頭中的萬用字元亦不再代表所有值。
結果顯示通過，是否代表實際請求一定成功？
不是。結果只適用於已貼上的回應及此處輸入的請求資料。重新導向、緩存回應、伺服器規則變更、瀏覽器擴充程式，以及預檢後的實際回應仍可能改變結果。