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 には何もアップロードまたは保存されません。

    よくある質問

    実際の応答を貼り付ける必要がありますか?それともプリフライト応答を貼り付ける必要がありますか?

    実際の応答を使用して、ブラウザー コードが 1 つの応答を読み取ることができるかどうかを確認します。後のメソッドとその要求されたヘッダー名を承認する OPTIONS 応答には、プリフライト応答を使用します。

    ワイルドカードが資格情報で失敗する可能性があるのはなぜですか?

    Cookie または HTTP 認証が含まれる場合、許可されるオリジンは要求元のオリジンと正確に一致する必要があります。許可されたメソッドとヘッダーのワイルドカードも、ワイルドカードの意味を失います。

    合格した結果は、ライブ リクエストが機能することを証明しますか?

    いいえ。この結果には、貼り付けられた応答とここに入力された要求の詳細のみが含まれます。リダイレクト、キャッシュされた応答、サーバー ルールの変更、ブラウザ拡張機能、およびプリフライト後の実際の応答によっても、結果が変わる可能性があります。

    CORSポリシーの仕組みと検証の重要性

    Cross-Origin Resource Sharing(CORS)は、あるオリジンから読み込まれたウェブアプリケーションが、異なるオリジンのリソースにアクセスできるようにブラウザーが制御する仕組みです。フロントエンド開発者、バックエンド開発者、APIプラットフォーム開発者、あるいはインフラの運用担当者にとって、ブラウザーのコードが特定の応答を正常に読み取れるかどうかを正確に把握することは極めて重要です。

    本ツール「CORS チェッカー」は、提供されたHTTP応答ヘッダーとリクエストの詳細に基づいて、ウェブブラウザーが特定のクロスオリジンリクエストを許可するかどうかを判定します。ユーザーが応答ヘッダーを貼り付け、オリジン、メソッド、リクエストヘッダーを指定し、資格情報の有無を選択することで、ブラウザーがそのリクエストを許可するかどうかをCORSポリシーに基づいて判定し、その理由を提示します。


    入力項目と検証ルール

    本ツールでは、以下の項目を入力または選択してCORSポリシーの検証を行います。

    1. 確認への返答

    「実際の反応」または「プリフライト応答」のいずれかを選択します。

    • 実際の反応: ブラウザーコードが1つの応答を直接読み取れるか確認する場合に使用します。
    • プリフライト応答: 実際のメソッドや要求されたヘッダー名を事前に承認するための OPTIONS 応答を検証する場合に使用します。

    2. HTTP 応答ヘッダー

    検証対象となるHTTP応答ヘッダーをテキストエリアに貼り付けます。プリフライト応答を検証する場合は、ステータス行も含めて貼り付ける必要があります。

    • 文字数制限: 最大200,000文字まで入力可能です。
    • エラー処理:
      • 未入力の場合: 「確認する前に HTTP 応答ヘッダーを貼り付けます。」と表示されます。
      • 制限超過の場合: 「この応答は異常に大きいです。 ‹max› 文字の下に保持します。」と表示されます。
      • 無効な行がある場合: 「‹line› 行は有効な HTTP ヘッダーまたはステータス行ではありません。」と表示されます。
      • 無効なヘッダー名がある場合: 「‹line› 行に無効な HTTP ヘッダー名が含まれています。」と表示されます。

    3. リクエスト元(Origin)

    リクエストを送信するオリジンのスキーム、ホスト、およびオプションのポートを入力します(例: https://app.example.com)。

    • 制約: パス、クエリパラメータ、または資格情報を含まない、純粋なオリジンまたは null である必要があります。
    • エラー処理: 形式が正しくない場合、「スキーム、ホスト、およびオプションのポート (https://app.example.com など) のみを含むオリジンを入力します。」と表示されます。

    4. 依頼方法(Method)

    リクエストで使用するHTTPメソッドを入力します。

    • エラー処理:
      • 無効なトークンの場合: 「有効な HTTP メソッド トークンを入力します。」と表示されます。
      • ブラウザーで禁止されているメソッドの場合: 「ブラウザでは、fetch リクエストで ‹method› メソッドを使用できません。」と表示されます。

    5. 要求されたヘッダー名

    Access-Control-Request-Headers に対応するヘッダー名を、カンマまたは改行で区切って入力します(例: Content-Type、Authorization)。

    • エラー処理: 無効なヘッダー名が含まれる場合、「「‹header›」は有効な HTTP リクエスト ヘッダー名ではありません。」と表示されます。

    6. 認証情報を含める(Credentials)

    CookieやHTTP認証などの資格情報をリクエストに含める場合は、このトグルをオンにします。


    判定結果と評価基準

    ツールは入力された情報を評価し、以下のいずれかの「ブラウザの決定」を出力します。

    • 貼り付けられた CORS レスポンスによって許可されます。
    • 貼り付けられた CORS レスポンスによってブロックされました。
    • ヘッダーは合格しますが、プリフライト ステータスは不明です。
    • 応答とリクエストの詳細を入力し、CORS ポリシーを確認します。(未入力時)
    • 応答を貼り付けて、CORS ポリシーを確認します。(初期状態)

    判定理由の解説

    判定結果とともに、以下の詳細な理由が表示されます。

    評価対象 判定理由の表示内容
    オリジン ・Access-Control-Allow-Origin は ‹origin› と完全に一致します。<br>・Access-Control-Allow-Origin では、このリクエストの任意の送信元が許可されます。<br>・Access-Control-Allow-Origin がありません。<br>・資格情報が含まれる場合、Access-Control-Allow-Origin を * にすることはできません。<br>・Access-Control-Allow-Origin は、‹expected› ではなく、‹actual› です。<br>・Access-Control-Allow-Origin に無効な値があります: ‹value›
    資格情報 ・Access-Control-Allow-Credentials はまさに true です。<br>・資格証明付きリクエストには Access-Control-Allow-Credentials: true が必要です。<br>・資格情報は含まれていないため、Access-Control-Allow-Credentials はこの決定に影響しません。
    ステータス ・プリフライト ステータス ‹status› は成功です。<br>・プリフライト ステータス ‹status› は、成功した 2xx ステータスではありません。<br>・HTTP ステータス行が貼り付けられていないため、必要な 2xx プリフライト ステータスを確認できません。
    メソッド ・プリフライトでは ‹method› が許可されます。<br>・‹method› は、CORS セーフリストに登録されたメソッドであり、Access-Control-Allow-Methods に指定する必要はありません。<br>・Access-Control-Allow-Methods は ‹method› を許可しません。
    ヘッダー ・リクエストされたヘッダー名にはプリフライトの承認は必要ありません。<br>・プリフライトでは、要求されたヘッダー名 ‹headers› が許可されます。<br>・Access-Control-Allow-Headers: * は、資格情報のないリクエストの名前 ‹headers› をカバーします。<br>・Access-Control-Allow-Headers は ‹headers› を許可しません。<br>・Authorization は明示的にリストする必要があります。 Access-Control-Allow-Headers: * ではカバーされません。

    CORSポリシーにおける重要なルールと注意点

    CORSの仕様には、いくつかの厳格なルールとエッジケースが存在します。

    • 資格情報とワイルドカードの制限: リクエストに資格情報(CookieやHTTP認証)が含まれる場合、Access-Control-Allow-Origin にワイルドカード(*)を指定することはできません。また、資格情報が含まれる場合、許可されるメソッドやヘッダーにおけるワイルドカードもその意味を失い、明示的な指定が必要になります。
    • 複数オリジンの禁止: Access-Control-Allow-Origin に複数の値が指定されていたり、カンマで区切られていたりする場合は、無効な値として扱われます。
    • 資格情報の明示的許可: 資格情報を伴うリクエストでは、Access-Control-Allow-Credentials が正確に true である必要があります。
    • Authorizationヘッダーの例外: 資格情報を含まないリクエストであっても、Authorization ヘッダーは Access-Control-Allow-Headers: * によるワイルドカード許可の対象外となります。必ず Access-Control-Allow-HeadersAuthorization を明示的にリストしなければなりません。
    • プリフライトのステータスコード: プリフライト応答を検証する際、HTTPステータス行が貼り付けられていない場合、必要な2xxステータスの確認が行えないため、結果は「ヘッダーは合格しますが、プリフライト ステータスは不明です。」(不定)となります。

    プライバシーと処理について

    本ツールで入力されたヘッダー情報やリクエストの詳細は、すべてユーザーのブラウザー内でのみ処理されます。外部のサーバーにアップロードされたり、BroBroGoに保存されたりすることはありません。

    また、本ツールは貼り付けられた応答ヘッダーと入力されたリクエスト詳細のみを静的に検証します。実際に外部サーバーと通信を行ったり、URLを読み込んだり、Cookieを設定したり、DNSやTLSのチェックを行ったり、サーバーの設定を変更したりすることはありません。


    よくある質問(FAQ)

    実際の応答を貼り付ける必要がありますか?それともプリフライト応答を貼り付ける必要がありますか?

    実際の応答を使用して、ブラウザー コードが 1 つの応答を読み取ることができるかどうかを確認します。後のメソッドとその要求されたヘッダー名を承認する OPTIONS 応答には、プリフライト応答を使用します。

    ワイルドカードが資格情報で失敗する可能性があるのはなぜですか?

    Cookie または HTTP 認証が含まれる場合、許可されるオリジンは要求元のオリジンと正確に一致する必要があります。許可されたメソッドとヘッダーのワイルドカードも、ワイルドカードの意味を失います。

    合格した結果は、ライブ リクエストが機能することを証明しますか?

    いいえ。この結果には、貼り付けられた応答とここに入力された要求の詳細のみが含まれます。リダイレクト、キャッシュされた応答、サーバー ルールの変更、ブラウザ拡張機能、およびプリフライト後の実際の応答によっても、結果が変わる可能性があります。