Origin Allowlist Check

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

状態

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

使い方

Origin と許可リストを貼り付けて「判定」。一致結果を表示します（Origin: 行/複数行貼り付けOK）。

注意（このツール）

  • このツールは「規則の簡易判定」です。実際のCORS挙動はサーバー実装と設定に依存します。

このページについて

何をするツール？

Origin が許可リストに一致するかを判定し、CORSの許可設定のズレを素早く見つけます。

サブドメイン許可やポート指定のミスでCORSが通らないケースの切り分けに向きます。

基本（許可リストの考え方）

  • Origin は scheme + host + port の組み合わせです。
  • 許可リストは「明示的な一致」が基本です。
  • ワイルドカードは最小限に使うのが安全です。

このツールの判定ルール

  • 完全一致: https://example.com
  • サブドメイン許可: https://*.example.com
  • 任意ポート: https://example.com:*
  • null Origin: null

スキームは必須、ホストは小文字で比較します。*.example.com は example.com 自体には一致しません。

入力の例

  • Origin: https://app.example.com
  • Allowlist: https://example.com
  • Allowlist: https://*.example.com

よくある落とし穴

  • Origin は host だけではない（scheme/portも含む）
  • example.com と *.example.com は一致しない
  • 許可しすぎ（*）でセキュリティリスクが増える

ベストプラクティス（安全な許可リスト）

  • 本番は完全一致を基本にし、ワイルドカードは最小限にする
  • ステージング/検証は別ドメインで管理する
  • ポート許可（:*）は必要最小限。明示的なポート指定が安全

確認のしかた（実測）

Origin の値はブラウザから実際のリクエストを送ることで確認できます。curl で Origin を付けて検証するのも有効です。

  • curl -I -H \"Origin: https://app.example\" https://api.example
  • Access-Control-Allow-Origin の戻りを確認して一致するかを見ます

トラブル別チェックリスト

  • CORSが通らない: Origin の scheme/port が許可リストと一致しているか確認
  • 一部だけ通らない: サブドメイン/ポートの差分が原因のことが多い
  • 想定外が通る: ワイルドカードの範囲が広すぎないか確認

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

  • Request Headers Parser で Origin を抽出
  • このツールで許可リストとの一致を確認
  • Host/Authority/Origin Inspect でHost/Originの違いを整理
  • Host/Authority/Origin Inspect
  • CORS Checklist
  • Request Headers Parser

このツールでできること

  • Origin と許可リストの一致判定
  • サブドメイン/ポートの許可判定
  • 複数Origin/複数ルールの一括判定

注意（運用）

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

参照仕様

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

FAQ

null Origin はどう扱う？

file:// や sandboxed iframe などで null になることがあります。許可する場合は意図を明確にしてください。

ワイルドカードは安全？

範囲が広がるため、最小限にするのが安全です。特に “*” は避けるのが無難です。

参考リンク

  1. RFC 6454
  2. Fetch Standard
  3. MDN: CORS
  4. MDN: Origin

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

許可Originの境界条件を検証するページです。許可し過ぎと拒否し過ぎの両方を防ぎます。

  • サブドメイン許可が意図せず広がっていないか確認する
  • http/https とポート条件を別々に確認する
  • 開発用Originが本番許可に混入していないか確認する

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

  • allowlist はコードではなく設定ファイルで管理する
  • 正規表現許可を使う場合はテストケースを固定化する
  • 環境別（dev/stg/prod）に許可リストを分離する
  • 許可追加時は期限と理由を記録する

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

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

CORS

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