CORS 檢查器

檢查貼上的回應是否允許指定來源、請求方法與標頭通過瀏覽器跨來源存取。

回應檢查
檢查預檢響應時也貼上狀態行。
在 Origin 標頭中傳送的方案、主機和選用連接埠。
針對包含 cookie 或 HTTP 驗證的請求啟用。
瀏覽器決定

    解析的存取控製字段

    HTTP status
    Access-Control-Allow-Origin
    Access-Control-Allow-Credentials
    Access-Control-Allow-Methods
    Access-Control-Allow-Headers
    Access-Control-Expose-Headers
    Access-Control-Max-Age

    輸入回應和請求詳細信息,然後檢查 CORS 策略。

    貼上回應以檢查其 CORS 策略。

    回應標頭與請求資訊只在瀏覽器內處理,不會上傳或儲存到 BroBroGo。

    常見問題

    我應該貼上實際回應還是預檢回應?

    使用實際回應來檢查瀏覽器程式碼是否可以讀取一個回應。使用預檢響應作為 OPTIONS 回复,批准稍後的方法及其請求的標頭名稱。

    為什麼通配符會因憑證而失敗?

    當包含 cookie 或 HTTP 驗證時,允許的來源必須與請求的來源完全相符。允許的方法和標頭的通配符也會失去其通配符意義。

    通過的結果是否證明即時請求有效?

    否。此結果僅涵蓋貼上的回應和此處輸入的請求詳細資訊。重定向、快取回應、更改伺服器規則、瀏覽器擴充功能和預檢後的實際回應仍然可以改變結果。

    在進行 Web 開發時,跨來源資源共用(CORS)常是導致前端請求失敗的常見原因。CORS 檢查器是一款專為前端開發人員、後端開發人員、API 平台開發人員及運維工程師設計的線上工具。本工具能協助您評估瀏覽器是否會允許特定的跨來源請求。

    您只需貼上 HTTP 回應標頭,指定請求的來源、方法與標頭,並選擇是否包含憑證,工具便會依據瀏覽器的 CORS 規則進行解析,並說明其判定的具體原因。

    運作原理與輸入參數

    本工具完全在您的瀏覽器本機中進行解析與評估。回應標頭與請求資訊只在瀏覽器內處理,不會上傳或儲存到 BroBroGo。

    在使用工具時,您需要提供以下資訊:

    • 回應檢查:可選擇「實際反應」或「飛行前響應」。
    • HTTP 回應標頭:貼上伺服器回傳的標頭內容,長度上限為 200,000 個字元。若檢查預檢響應時也貼上狀態行。
    • 請求原產地:輸入發起請求的來源(包含配置方案、主機及選用連接埠),例如 https://app.example.com。此處必須是純來源,不可包含路徑、查詢參數或憑證資訊。
    • 請求的方法:例如 GETPOSTOPTIONS 等標準 HTTP 方法。
    • 請求的標頭名稱:對應 Access-Control-Request-Headers 中的名稱,多個標頭請以逗號或換行分隔。
    • 包括憑證:若請求包含 Cookie 或 HTTP 驗證,請啟用此切換開關。

    瀏覽器決策與判定邏輯

    當您輸入資料並點擊「檢查CORS」後,工具會輸出「瀏覽器決定」並列出「解析的存取控製字段」與判定原因。常見的判定原因與規則如下:

    來源檢查(Access-Control-Allow-Origin)

    • 完全匹配:當 Access-Control-Allow-Origin 與請求來源完全相符時,顯示「Access-Control-Allow-Origin 與 ‹origin› 完全匹配。」。
    • 萬用字元:在不含憑證的請求中,若設定為 *,顯示「Access-Control-Allow-Origin 允許此請求的任何來源。」。
    • 憑證衝突:若啟用「包括憑證」,但來源設定為 *,則會判定失敗,顯示「當包含憑證時,Access-Control-Allow-Origin 不能是 *。」。
    • 多重值無效:若 Access-Control-Allow-Origin 包含多個值或以逗號分隔,將被視為無效值。

    憑證檢查(Access-Control-Allow-Credentials)

    • 對於包含憑證的請求,Access-Control-Allow-Credentials 必須明確為 true。若未提供,則會顯示「憑證請求需要 Access-Control-Allow-Credentials: true。」。

    預檢狀態與方法檢查

    • 狀態碼要求:預檢回應必須包含成功的 2xx 狀態碼。若未貼上狀態列,則無法驗證,顯示「未貼上 HTTP 狀態行,因此無法檢查所需的 2xx 預檢狀態。」。
    • 方法授權:若請求方法屬於 CORS 安全清單方法(如 GET),則不需出現在 Access-Control-Allow-Methods 中。否則,預檢回應必須明確允許該方法。

    標頭授權與 Authorization 的特殊限制

    • 若未包含憑證,Access-Control-Allow-Headers 可使用 * 允許所有標頭。
    • 特別注意Authorization 標頭具有特殊限制。即使設定了 Access-Control-Allow-Headers: *Authorization 仍必須在標頭名單中明確列出,否則會顯示「Authorization 必須明確列出;Access-Control-Allow-Headers:*不覆蓋。」。

    錯誤訊息與異常處理

    若輸入的資料格式不正確,工具會顯示對應的錯誤提示:

    • 空白輸入:在檢查之前貼上 HTTP 回應標頭。
    • 長度超限:這個反應異常大。將其保留在 ‹max› 字元下。
    • 無效標頭行‹line› 行不是有效的 HTTP 標頭或狀態列。
    • 無效來源格式:輸入僅包含方案、主機和選用連接埠的來源,例如 https://app.example.com。
    • 禁用方法:瀏覽器不允許在 fetch 請求中使用 ‹method› 方法。

    工具評估的局限性

    本工具僅依據您貼上的回應標頭與輸入的請求詳細資訊進行靜態規則分析。本工具不會連線至伺服器,無法讀取實際 URL、設定 Cookie、檢查 DNS/TLS,亦無法修改您的伺服器設定。

    通過檢查並不代表實際網路請求必定成功。在實際瀏覽器環境中,重新導向、快取機制、動態變更的伺服器規則、瀏覽器擴充功能,或是預檢後的實際回應內容,都可能影響最終的跨來源存取結果。

    常見問題

    我應該貼上實際回應還是預檢回應?

    使用實際回應來檢查瀏覽器程式碼是否可以讀取一個回應。使用預檢響應作為 OPTIONS 回复,批准稍後的方法及其請求的標頭名稱。

    為什麼通配符會因憑證而失敗?

    當包含 cookie 或 HTTP 驗證時,允許的來源必須與請求的來源完全相符。允許的方法和標頭的通配符也會失去其通配符意義。

    通過的結果是否證明即時請求有效?

    否。此結果僅涵蓋貼上的回應和此處輸入的請求詳細資訊。重定向、快取回應、更改伺服器規則、瀏覽器擴充功能和預檢後的實際回應仍然可以改變結果。