CORS Checklist

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

CORSチェックリスト

  • Access-Control-Allow-Origin は期待するオリジンを返しているか
  • Credentials 利用時に Allow-Origin が * になっていないか
  • Access-Control-Allow-Methods が必要メソッドを含むか
  • Access-Control-Allow-Headers が必要ヘッダーを含むか
  • Access-Control-Allow-Credentials の有無が仕様通りか
  • Access-Control-Expose-Headers が必要なヘッダーを含むか
  • Preflight（OPTIONS）が 2xx で返っているか
  • Preflight に不要なリダイレクトがないか
  • Vary: Origin が必要な場合に付いているか
  • Cache-Control がCORS結果を適切に扱っているか

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

使い方

上から順に項目を確認し、実際のレスポンスヘッダーと照合してください。不一致の項目を特定してから個別診断ツールに進むと効率的です。

注意（このツール）

  • このページはチェックリストです。実際のヘッダー確認は HTTP Header Parser と併用してください。
  • Preflight（OPTIONS）と本リクエストで挙動が異なる場合があります。両方のヘッダーを確認してください。

このページについて

何をするツール？

CORS（Cross-Origin Resource Sharing）の設定を確認するためのチェック項目をまとめています。

Access-Control-* ヘッダーの組み合わせや、プリフライトの要件を確認できます。

CORSは「ブラウザの安全制約」で、サーバー側の許可ヘッダーが正しくないと fetch/XHR が失敗します。

CORSの基本（最短）

  • 同一オリジン以外へのリクエストは「クロスオリジン」になります。
  • サーバーは Access-Control-Allow-Origin などのレスポンスヘッダーで許可を示します。
  • 条件によってはプリフライト（OPTIONS）が発生します。

よくある状況

  • フロント（https://app.example）→ API（https://api.example）で失敗する
  • Cookie付き（credentials）で失敗する
  • Authorization ヘッダーを付けたらプリフライトで失敗する

典型パターン（ヘッダーの組み合わせ）

  • 単純なGETでCookie不要：Allow-Origin を許可（* でも可）
  • Cookie付き（credentials=true）：Allow-Origin は具体値、Allow-Credentials: true
  • Authorization等でプリフライト：Allow-Methods/Allow-Headers を揃える

よくあるエラー例

  • No 'Access-Control-Allow-Origin' header is present...
  • The value of 'Access-Control-Allow-Origin' must not be '*' when credentials are included...
  • Request header field Authorization is not allowed by Access-Control-Allow-Headers...

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

  • 実際のレスポンスヘッダーを確認（HTTP Header Parser へ貼る）
  • プリフライト（OPTIONS）のレスポンスも確認
  • credentials の有無、送っているヘッダー/メソッドを整理

チェック項目（概要）

  • Access-Control-Allow-Origin の値が正しいか
  • Credentials 利用時に * を使っていないか
  • Allow-Methods / Allow-Headers の整合
  • Preflight（OPTIONS）の応答が正しいか

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

  • 対象ヘッダーを貼り付ける
  • 不足・過剰なポリシーを確認する
  • Report-Onlyや段階反映で検証する

注意（運用）

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

参照仕様

  • Fetch Standard（CORS）
  • RFC 9110（HTTP Semantics）
  • MDN（CORS / Preflight）

FAQ

CORSはサーバー側の設定？

はい。CORSの許可はサーバーがレスポンスヘッダーで行います。

Access-Control-Allow-Origin に複数オリジンは書けますか？

できません。通常はリクエストの Origin を見て1つを返すか、* を使います（credentials時は * 不可）。

参考リンク

  1. Fetch Standard
  2. MDN: CORS

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

導入漏れ防止のための実務チェックです。CORS設定変更時のレビュー項目として利用します。

  • Origin許可方針が要件と一致しているか確認する
  • Preflight応答が method/header 要件を満たすか確認する
  • 認証付きリクエストの credentials 条件を確認する

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

  • リリース前チェック項目に CORS Checklist を固定化する
  • 仕様変更時はフロントとAPI両チームで同時レビューする
  • 監視に CORS失敗率 を追加する
  • 問題再発時はチェックリスト差分を監査する

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

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

CORS

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