本文へスキップ

CORSテスター

CORS Tester

指定した生成元からブラウザが送るプリフライトとOriginを載せたGETを実際に送り、Fetch標準の規則でどのヘッダーが止めたのかを説明します。

コンソールに出るCORSの失敗は、足りなかったヘッダーの名前は言いますが、理由はほとんど言いませんし、ブラウザが実際に送ったリクエストはあなたのコードにあるものとは違います。ここでは、指定した生成元からブラウザが送るはずのプリフライトを送り、続けてそのOriginを載せたGETを送り、その結果をFetch標準の規則に照らして読みます。

☁️ サーバーを使いますcorshttpdebugweb

このリクエストは、こちらのサーバーが代わりに送ります。サーバーに渡るのは入力した URL・オリジン・メソッド・ヘッダー名だけで、ブラウザの Cookie やログイン状態は一緒に送られません。サーバーは公開アドレスにしか接続せず、プライベートアドレスや内部アドレスへの接続は拒否します。

ブラウザが送るはずのプリフライト(OPTIONS)と実際のリクエストをサーバーが代わりに送り、Fetch 標準の CORS 規則で判定します。実際のリクエストはいつも GET(または HEAD)です — 他人の API に PUT や DELETE を代わりに撃つことはありません。

呼び出し元のウェブページのスキーム・ホスト・ポートです。

application/json は必ずプリフライトを起こします。

使い方

  1. URLと生成元を入れます

    生成元は、そのリクエストがどこから出るかです。呼び出す側のページであって、APIではありません。この2つを逆にすることが、検査結果とブラウザの動きが食い違ういちばん多い理由です。

  2. 実際に使うメソッドとヘッダーを入れます

    プリフライトは、単純でないリクエストのときにしか起きません。それを引き起こすのは`Content-Type: application/json`や`Authorization`ヘッダーなので、それらを抜いたまま検査すると、実際には出さないリクエストを検査することになります。

  3. どの規則で落ちたかを読みます

    結果は、生成元が許可されていない、メソッドが挙げられていない、ヘッダーが挙げられていない、ワイルドカードの生成元に資格情報を付けている、といった具体的な検査項目を名指しします。漠然とした失敗としては報告しません。

よくある質問

ここでは通るのに、ブラウザではまだ遮断されます。

メソッド、ヘッダー、資格情報のモードが、コードの送っているものと厳密に一致しているかを確かめてください。またサーバーが、クッキーやユーザーエージェントによってレスポンスを変えていないかも確かめてください。これはサーバーから走るので、あなたが持っているセッションに依存するレスポンスとは違うものが返ります。

`Access-Control-Allow-Origin: *`がクッキーと一緒に効かないのはなぜですか。

標準が禁じているからです。`credentials: 'include'`のときは、生成元をそのまま返し、`Access-Control-Allow-Credentials: true`も付けなければなりません。資格情報付きのワイルドカードは、不具合ではなく設計として拒否されます。

これはブラウザの中で走りますか。

いいえ。サーバーから走ります。CORSが遮断するリクエストを、ブラウザは出せないからです。つまり見えているのは公開されたレスポンスであって、あなたのクッキーもネットワーク上の位置も入っていません。

社内のアドレスも検査できますか。

できません。リクエストは、あなたのネットワークに届かないサーバーから出ます。そのネットワークの中でしか解決しないアドレスは、CORSの設定がどうであれ失敗します。

ここから渡せます

次の一手

このツールが出したものをそのまま受け取れる道具です。