CORS プリフライト シミュレーター
無料のオンライン CORS シミュレーター。要求とサーバーの Access-Control-Allow ヘッダーを入力すると、ブラウザが許可か拒否か、どのヘッダーが不足かが即座に分かります。
CORS プリフライト シミュレーター
無料のオンライン CORS シミュレーター。要求とサーバーの Access-Control-Allow ヘッダーを入力すると、ブラウザが許可か拒否か、どのヘッダーが不足かが即座に分かります。
CORS について
なぜブラウザはクロスオリジンの読み取りを拒否するか
既定ではページは自分と同じ origin のレスポンスしか読めません。別の origin のレスポンスを読ませるには、サーバーが Access-Control-Allow-* ヘッダーで許可する必要があります。ブラウザがこれを強制し、ヘッダーが自分の origin を許可していなければ、サーバーが応答していても読み取りを拒否します。
プリフライトと credentials のルール
シンプルでない要求（カスタムヘッダー、JSON ボディ、GET/HEAD/POST 以外のメソッド）はまず OPTIONS プリフライトを送り、サーバーがメソッドとヘッダーを許可して初めて実際の要求が出ます。要求が credentials を伴う場合、ワイルドカードは効かなくなります。Access-Control-Allow-Origin は正確な origin（* 不可）でなければならず、Access-Control-Allow-Credentials は true が必須です。この厳密な組み合わせが最も多い CORS のミスです。
よくある質問
このテーマに関するよくある疑問と回答をまとめました。
サーバーは応答しているのに、なぜ CORS が要求を拒否するのですか？
サーバーは応答していますが、Access-Control-Allow-* ヘッダーがあなたの origin（やメソッド、ヘッダー）を許可していないため、ブラウザがレスポンスをページに渡すのを拒否します。本ツールはどのヘッダーが不足かを示します。
CORS プリフライトとは何ですか？
シンプルでない要求では、ブラウザはまず OPTIONS 要求を送り、メソッドとヘッダーが許可されるかをサーバーに尋ねます。そのプリフライトが通ったときだけ実際の要求が出ます。
なぜ credentials ありだと Access-Control-Allow-Origin: * が失敗するのですか？
セキュリティ上、要求が cookie や認証を送る場合ブラウザはワイルドカードを禁止します。正確な origin を返し、Access-Control-Allow-Credentials: true を付ける必要があります。
このツールは実際の要求を送りますか？
いいえ。完全にブラウザ内で動く純粋なルールエンジンで、ネットワーク要求は一切送らず、入力内容が端末外に出ることもありません。