CORS Diagnostic

セキュリティヘッダー/ポリシーをブラウザ内で診断します。入力はサーバーへ送信しません。段階導入前の一次確認に使えます。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。まずはここで一次切り分けしてください。

使い方

Request/Response Headers を貼り付けて「診断」。CORSの通過可否と原因を表示します。

注意（このツール）

  • Preflight（OPTIONS）と本リクエストでヘッダーが異なると判定が変わるため、両方を確認してください。
  • 資格情報付きリクエストでは Allow-Origin=* は使えません。Allow-Credentials とセットで確認します。

このページについて

何をするツール？

Origin / Access-Control-* の組み合わせから、CORSの通過可否を整理します。

切り分け手順（おすすめ）

  • Request/Response Headers を貼り付け
  • Summary で原因を確認
  • CORS Response Inspect で詳細を確認

推奨（実務）

  • Credentials を使うなら Allow-Origin は * にしない
  • 動的 Origin は Vary: Origin を付与
  • Preflight は Allow-Methods/Allow-Headers を明示
  • CORS Response Inspect
  • CORS Checklist
  • Origin Allowlist Check
  • Host/Authority/Origin Inspect

このツールでできること

  • CORSの可否を要点で判定
  • よくある設定ミスを検出

注意（運用）

  • 推奨値は環境依存です。機能要件と衝突しないか検証してから適用してください。
  • 本番では段階導入とレポート監視を併用してください。

参照仕様

  • MDN: CORS
  • Fetch Standard

FAQ

preflight はいつ発生しますか？

非単純メソッドや特定ヘッダーを使うと OPTIONS の事前確認が発生します。

ACAO=* と credentials は併用できますか？

できません。credentials を使う場合は明示的な Origin を返す必要があります。

参考リンク

  1. MDN: CORS
  2. Fetch Standard

症状別ケーススタディ（このページ向け）

CORS全体を俯瞰して原因を絞る用途です。Origin、Preflight、資格情報の3点を同時に確認します。

  • 失敗リクエストの Origin と Allow-Origin の一致を確認する
  • Preflight (OPTIONS) のステータスと Allow-* を確認する
  • credentials 利用時に wildcard を使っていないか確認する

実装時チェックリスト（このページ向け）

  • CORS設定はAPI単位で最小許可にする
  • プリフライト失敗ログに method/header/origin を記録する
  • Allow-Headers は実際に必要な値のみ許可する
  • 設定変更時は主要ブラウザで再検証する

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. CORS Error Troubleshooting — CORSエラー文とヘッダーを突き合わせて失敗ポイントを症状別に切り分け
  2. CORS Response Inspect — Access-Control-Allow-* を解析してCORS応答を点検
  3. Origin Allowlist Check — Origin と許可リストの一致を判定
  4. CORS preflight失敗時の診断手順 — OPTIONS応答、Allow-*、Origin条件を順に確認して preflight 失敗を解消する
  5. CORS系ツールの使い分け — preflight失敗・Origin不一致・credentials競合を症状から切り分ける
  6. CORS Checklist — CORS設定の確認項目を手順化
  7. Host/Authority/Origin Inspect — Host/:authority/Origin/Referer を照合して不整合を確認

CORS

Origin と Allow-* を比較して CORS 許可判定を点検