CORS Error Troubleshooting

CORSエラーの文面とヘッダーをブラウザ内で照合し、どこでブロックされたかを段階的に特定します。入力はサーバーへ送信しません。

状態

ブラウザ内で処理します。入力はサーバーへ送信しません。エラー文とヘッダーを一緒に貼ると精度が上がります。

使い方

コンソールエラー文（CORS policy...）と Request/Response ヘッダーを貼り付け、「切り分け」を押します。空行区切りで貼っても、そのまま連結貼りでも解析できます。

注意（このツール）

  • この診断は一次切り分けです。最終確認はブラウザのNetworkタブで OPTIONS と本リクエストを比較してください。
  • Authorization や Cookie 等の機密値は伏せ字化して貼り付けてください。

このページについて

何をするツール？

Chrome/Edge/Firefox のコンソールに出る CORS エラー文と、Request/Response ヘッダーを突き合わせて、失敗原因を候補化します。

「preflightが通っていないのか」「Originが不一致なのか」「credentialsと*の組み合わせミスか」を短時間で切り分けるための症状起点ハブです。

よくある症状

  • No 'Access-Control-Allow-Origin' header が出る
  • preflight request doesn't pass access control check
  • Request header field ... is not allowed by Access-Control-Allow-Headers
  • The value of Access-Control-Allow-Origin must not be * when credentials flag is true
  • Redirect is not allowed for a preflight request / CORS request did not succeed

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

  • コンソールエラー全文と Request/Response ヘッダーを貼り付ける
  • Diagnosis セクションで「BLOCKED要因」を先に確認する
  • Preflight 条件（Method/Headers/Status）を確認する
  • Origin / Allow-Origin / Credentials / Vary を照合する
  • 関連ツールで個別値を深掘りする

CORSではない可能性

  • DNS/TLS/証明書エラーや mixed content（httpsページからhttp呼び出し）
  • APIゲートウェイ/WAF/CDNで OPTIONS が遮断されている
  • サーバー間通信（バックエンド-to-バックエンド）はブラウザCORS制約の対象外

推奨（実務）

  • credentials を使う時は Access-Control-Allow-Origin を具体的Originで返す（*禁止）
  • Originを動的返却するなら Vary: Origin を付与する
  • preflight用 OPTIONS ルートを用意し、2xx + 必要な Allow-* を返す
  • Authorization 等を使う場合は Access-Control-Allow-Headers を明示する
  • CORS Diagnostic
  • CORS Response Inspect
  • Origin Allowlist Check
  • Host/Authority/Origin Inspect
  • Request Headers Parser
  • Response Headers Parser

このツールでできること

  • CORSエラー文とヘッダーの突き合わせ診断
  • preflight失敗（Method/Header/Status）候補の抽出
  • Origin不一致・credentials設定ミス・Vary不足の検出
  • 次に確認すべき項目と関連ツールへの導線提示

注意（運用）

  • 実際の判定はブラウザ実装差分の影響を受けます。複数ブラウザで再現確認してください。
  • この診断は貼り付けた情報に依存します。Networkタブで実際のOPTIONS/本リクエスト両方を取得してください。
  • 機密トークンは伏せ字化して貼り付ける運用を推奨します。

参照仕様

  • Fetch Standard（CORS protocol）
  • RFC 6454（The Web Origin Concept）
  • MDN: CORS / CORS errors
  • Private Network Access（PNA）

FAQ

preflightが失敗しているかはどう見分けますか？

Access-Control-Request-Method/Headers があり、OPTIONS応答が2xxでない・Allow-*不足・エラーメッセージにpreflight表現がある場合は preflight 失敗の可能性が高いです。

Access-Control-Allow-Origin: * は常に危険ですか？

公開API等では成立する場合がありますが、credentials併用時は仕様上無効です。認証付きエンドポイントでは具体的Origin返却が基本です。

サーバー側では成功しているのにブラウザだけ失敗するのはなぜ？

CORSはブラウザのセキュリティ制約です。バックエンド-to-バックエンド通信には通常適用されず、ブラウザ経由時のみブロックされます。

参考リンク

  1. Fetch Standard: CORS protocol
  2. RFC 6454
  3. MDN: CORS
  4. MDN: CORS errors
  5. Private Network Access

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

ブラウザの具体的なエラーメッセージを起点に、設定ミスを短時間で切り分ける用途です。

  • "No Access-Control-Allow-Origin" 系は応答経路でヘッダー欠落を疑う
  • "preflight did not succeed" は OPTIONS ルート/認可設定を確認する
  • "credentials" 系は Allow-Origin と Allow-Credentials の組み合わせを確認する

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

  • エラーメッセージごとの一次対応手順を運用手順書に持つ
  • API gateway と app server の両方で OPTIONS を通す
  • CORSエラー発生時に request-id でサーバーログ追跡可能にする
  • 修正後は実ブラウザで同一シナリオを再テストする

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

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

CORS

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