CORSテスター

次へ

CORSエラーは「定番」のブラウザコンソールの赤です。別オリジンのAPIにアクセスすると、ブラウザがレスポンスをブロックします。このテスターは、貼り付けた任意のURLに対して、選択したオリジンとメソッドでプリフライトのOPTIONSリクエストを送り、Access-Control-* ヘッダーを解読します。サーバーが何を許可し、何をブロックし、なぜブラウザが文句を言うのかを正確に確認できます。

CORSをテストする方法

  1. 1

    対象のURLを入力

    フロントエンドから呼び出したいAPIのエンドポイント。クエリ文字列とプロトコルを含めます。

  2. 2

    メソッドとオリジンを設定

    GET/POST/PUT/DELETE/PATCH。オリジンは自分のサイトのURL、またはシミュレートしたい任意のオリジンにできます。

  3. 3

    プリフライトを理解する

    テスターは常に、選択したオリジンとメソッドに加えてAccess-Control-Request-Headers: Content-Typeヘッダー付きのOPTIONSリクエストを送信します。これはブラウザがJSONリクエストの前に送るプリフライトとまったく同じです。

  4. 4

    テストを実行

    テスターはプリフライトを送信し、HTTPステータスとCORSレスポンスヘッダー(Allow-Origin、Allow-Methods、Allow-Headers、Allow-Credentials、Max-Age)を報告します。

  5. 5

    設定ミスを修正

    レポートが、欠けているものや誤っているもの:Allow-Originの欠如、禁止されたヘッダー、許可されていないメソッド:を指摘します。

重要なヘッダー

ヘッダー 役割
Access-Control-Allow-Origin どのオリジンがレスポンスを読めるか
Access-Control-Allow-Methods プリフライト:許可されるメソッド
Access-Control-Allow-Headers プリフライト:許可されるリクエストヘッダー
Access-Control-Allow-Credentials Cookie/認証が許可されるか
Access-Control-Expose-Headers JSが読めるレスポンスヘッダー
Access-Control-Max-Age プリフライト結果がキャッシュされる時間

単純リクエスト vs. プリフライト付きリクエスト

リクエストが「単純」(プリフライトなし)であるのは、次のすべてが真の場合だけです。

  • メソッドがGET、HEAD、またはPOSTである。
  • ヘッダーがAccept、Accept-Language、Content-Language、Content-Type(特定の値)に限られる。
  • Content-Typeがある場合、それがapplication/x-www-form-urlencoded、multipart/form-data、またはtext/plainである。

それ以外のもの、JSONボディ、Authorizationヘッダー、カスタムのX-Fooヘッダー、PUT/DELETE/PATCH、はプリフライトのOPTIONSを引き起こします。サーバーは正しいAllow-* ヘッダーでプリフライトに応答しなければ、実リクエストは発火しません。

よくあるCORSの失敗

  • 「No Access-Control-Allow-Origin header」 → サーバーがヘッダーを設定していない。クライアントではなくサーバーで修正します。
  • *「Credentials mode requires Allow-Origin not to be → Cookieを送る場合、Allow-Originは特定のオリジン(またはOriginヘッダーの反射)でなければなりません。
  • 「Request header X not allowed」 → プリフライトのレスポンスのAccess-Control-Allow-HeadersにXを追加します。
  • 「Method not allowed」Access-Control-Allow-Methodsにメソッドを追加します。
  • 「Redirect not allowed in preflight」 → プリフライトはリダイレクトを追えません。OPTIONSのエンドポイントが直接応答しなければなりません。

Allow-Origin: * vs. Originの反射

Access-Control-Allow-Origin: *は寛容ですが、資格情報と組み合わせられません。本番では、(許可リストに対して検証したうえで)リクエストのOriginを反射し、Cookieが必要ならAllow-Credentials: trueを設定します。

回避策としてのプロキシ

サーバーを制御できない場合、自分のドメイン上の薄いプロキシがCORSを完全に取り除きます、ブラウザには同一オリジンに見えます。多くのホスティングプラットフォーム(Vercel、Netlify、Cloudflare)が、まさにこのための書き換えルールを提供しています。

よくある質問

悪意のあるページが、あなたのブラウザのCookieを使って別サイトの非公開データを読むのを防ぐためです。CORSがなければ、evil.comを訪れると、あなたとして銀行の内部APIにリクエストできてしまうかもしれません。CORSは銀行にクロスオリジンの読み取りを明示的に許可させます。

開発時のみです。Chromiumには--disable-web-securityフラグがありますが、すべてのサイトに影響し危険です。正しい修正は、サーバー側のヘッダーまたはプロキシです。

Postmanはブラウザではなく、CORSを完全に無視します。CORSはブラウザによってJavaScriptのリクエストにのみ強制されます。Postmanで動くサーバーが、自動的にCORS的に正しいわけではありません。

画像や従来の<script>タグはCORSなしでクロスオリジンに読み込まれますが、JSはその内容を読めません。<img crossorigin>fetch()はCORSを強制するため、それがないとcanvasに描いた画像が「汚染」されます。

関連ツール