CORS Response Inspect

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

状態

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

使い方

Access-Control-Allow-* を貼り付けて「解析」。許可内容を一覧表示します（ヘッダー行/複数行貼り付け/ヘッダー全体貼り付けOK）。

注意（このツール）

  • 実際のCORS挙動はリクエスト内容とサーバー実装に依存します。

このページについて

何をするツール？

Access-Control-Allow-Origin/Methods/Headers/Credentials などのヘッダーを分解し、許可内容を一覧表示します。

「CORSが通らない」「許可範囲が広すぎる」などの原因切り分けに向きます。

基本（CORSレスポンス）

  • CORSはレスポンスヘッダーで許可を表します。
  • Access-Control-Allow-Origin は必須、他はケースにより必要です。
  • 資格情報（Credentials）を使う場合、* は使えません。
  • 「単純リクエスト」と「プリフライト（OPTIONS）」で確認ポイントが変わります。

用語（ざっくり）

  • Origin: ブラウザが送る「どこから来たか」（scheme+host+port）。
  • 単純リクエスト（Simple request）: 一部条件を満たすと preflight が省略されます。
  • プリフライト（Preflight）: 本番リクエスト前に OPTIONS で許可を問い合わせます。
  • Credentials: Cookie/Authorization など“認証付き”に近い扱い（ブラウザ側で opt-in）。
  • Expose-Headers: JS から読み取れるレスポンスヘッダーを追加で公開します。

プリフライトで見るべきヘッダー

CORSで詰まる原因の多くは、実リクエストではなく preflight（OPTIONS）の許可不足です。

  • Access-Control-Allow-Methods: 実際に呼びたいメソッド（GET/POST/PUT...）が含まれるか
  • Access-Control-Allow-Headers: リクエストで送るヘッダー（Authorization 等）が含まれるか
  • Access-Control-Max-Age: preflight 結果のキャッシュ時間（ブラウザ依存で上限があります）

curlでの確認（簡易）

ブラウザを開かずに挙動を把握したい時は、まず curl で preflight を再現すると切り分けが速いです。

  • preflight（例）: curl -i -X OPTIONS https://api.example/endpoint -H \"Origin: https://app.example\" -H \"Access-Control-Request-Method: POST\" -H \"Access-Control-Request-Headers: content-type, authorization\"
  • 実リクエスト（例）: curl -i https://api.example/endpoint -H \"Origin: https://app.example\"

出てきた Access-Control-Allow-* をこのページに貼り付けると、許可内容を読みやすく整理できます。

入力の例

  • Access-Control-Allow-Origin: https://app.example
  • Access-Control-Allow-Methods: GET, POST
  • Access-Control-Allow-Headers: Content-Type, Authorization
  • Access-Control-Allow-Credentials: true

よくある落とし穴

  • Credentials=true なのに Allow-Origin が *（NG）
  • Origin を動的に返すのに Vary: Origin が無い
  • Allow-Headers が preflight の要求ヘッダーと一致しない
  • Allow-Methods が足りず OPTIONS は通るが本番が失敗する
  • Expose-Headers を付けず、JS から目的のヘッダーが読めない

Credentials（Cookie/認証）を使う時の要点

ブラウザが Cookie や Authorization を伴って呼ぶ場合は、許可設定が一段厳格になります。

  • Access-Control-Allow-Credentials: true を返す（必要な場合のみ）。
  • Access-Control-Allow-Origin は * ではなく、具体的な Origin を返す。
  • 複数Originを許可するなら、許可リストに基づいて動的に返し、Vary: Origin を付ける。

アプリ側（fetch）でも credentials: \"include\" のような opt-in が必要で、片方だけ整っても通りません。

キャッシュと Vary（混在事故を防ぐ）

CORSは「レスポンスを誰に見せるか」を変えるため、キャッシュが絡むと別Originの許可が混ざる事故が起きます。

  • Allow-Origin を動的に返すなら Vary: Origin を付ける（ほぼ必須）。
  • preflight（OPTIONS）をキャッシュさせるなら Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers も検討。
  • Max-Age を伸ばしすぎると、設定変更が反映されにくくなる点にも注意。

セキュリティ観点（許可しすぎの危険）

  • Origin を「受け取ったまま反射」すると、任意サイトに許可が広がる可能性があります。
  • Allow-Headers/Methods を広げすぎると、想定外のリクエストが通りやすくなります。
  • Credentials=true と組み合わせる場合は特に慎重に（Cookieが付くため影響が大きい）。

症状別チェックリスト

  • ブラウザが「CORS policy」に見えるエラー: まず preflight（OPTIONS）が 2xx か確認。
  • POST/PUT だけ失敗: Allow-Methods を確認。
  • Authorization を付けると失敗: Allow-Headers に authorization があるか確認。
  • Cookieで失敗: Allow-Credentials=true と Allow-Origin の具体値（* ではない）を確認。
  • JSでヘッダーが読めない: Expose-Headers を確認（例: X-Request-Id）。

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

  • Response Headers Parser で CORSヘッダーを抽出
  • このツールで許可内容を整理
  • Origin Allowlist Check で許可リストの一致を確認
  • Vary Inspect で Vary: Origin の有無を確認
  • Origin Allowlist Check
  • Host/Authority/Origin Inspect
  • CORS Checklist
  • Response Headers Parser
  • Request Headers Parser
  • Vary Inspect

このツールでできること

  • Access-Control-Allow-* の分解表示
  • Credentials/Expose-Headers の確認
  • Max-Age（preflightキャッシュ）を読みやすく表示
  • ヘッダー全体から CORSヘッダー抽出

注意（運用）

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

参照仕様

  • RFC 6454（Origin）
  • Fetch Standard（CORS）
  • MDN: CORS

FAQ

Allow-Origin に * はいつ使える？

Credentials を使わない場合に限ります。Credentials=true と同時はNGです。

Vary: Origin は必要？

Origin を動的に返す場合は必須に近いです。キャッシュ混在を防ぎます。

CORSエラーなのにHTTPは200になるのはなぜ？

ブラウザがレスポンスをJSに渡す前にブロックするためです。preflight（OPTIONS）の失敗や Allow-* の不一致が典型です。

Expose-Headers はいつ必要？

JS から独自ヘッダー（例: X-Request-Id）を読みたい時に必要です。付けないと取得できません。

参考リンク

  1. Fetch Standard
  2. RFC 6454
  3. MDN: CORS
  4. MDN: Access-Control-Allow-Origin
  5. MDN: Access-Control-Allow-Methods
  6. MDN: Access-Control-Allow-Headers
  7. MDN: Access-Control-Allow-Credentials
  8. MDN: Access-Control-Expose-Headers
  9. MDN: Access-Control-Max-Age
  10. MDN: Vary

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

レスポンス側の Access-Control-* 値を精査して、ブラウザ判定と一致しているかを確認するページです。

  • Allow-Origin の値が意図した1オリジンかを確認する
  • Allow-Methods が実際のメソッドを含むかを確認する
  • Expose-Headers がフロント実装要件を満たすかを確認する

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

  • レスポンスヘッダー生成箇所をアプリとプロキシで一本化する
  • Allow-Credentials の有無をセッション設計と合わせる
  • 可変Origin運用では Vary: Origin を必須化する
  • 障害時は raw headers を保存して再現性を担保する

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

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

CORS

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