リソース · 116

postMessage：送信元、ウィンドウ、要求を検証する

iframeやポップアップの通信契約で想定外の送信者とデータを拒否します。

更新済み · 3 min

このガイドが達成するのに役立つこと

  • 相手とメッセージ型を決める
  • 作用の前に検証する
  • 移動と契約外メッセージを試す

クイックチェック

  • origin、ウィンドウ、型、最小データの契約。
  • 検証順序と業務作用のない拒否。
  • 拒否一覧とリスナーの整理。

手順

  1. 1

    相手とメッセージ型を決める

    許可する正確なorigin、期待するウィンドウ参照、必要な型を記録します。機密データには明確なtargetOriginを使います。originは方式、ホスト、ポートを含み、ドメインの部分文字列では相手を確認できません。

    origin、ウィンドウ、型、最小データの契約。

  2. 2

    作用の前に検証する

    event.originと、この連携ではevent.sourceを期待するウィンドウと比較します。構造、許可値、処理状態を確認し、evalやHTML挿入をせずデータとして扱います。許可originもサーバー側の権限確認を代替しません。

    検証順序と業務作用のない拒否。

  3. 3

    移動と契約外メッセージを試す

    類似ドメイン、別ポート、同じoriginの別ウィンドウ、不正な項目、終了後のメッセージを試します。不要なリスナーを削除し、終了した通信を無効化します。移動後も返信先は事前承認したoriginに限定します。

    拒否一覧とリスナーの整理。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "allowed_origin": "https://widget.example",
    "observed_origin": "https://widget.example",
    "expected_window": "active_iframe",
    "observed_window": "another_window",
    "payload_schema_valid": true,
    "expected": "reject_without_effect"
}

期待される判断

架空例：https://widget.exampleは許可済みですがevent.sourceは別ウィンドウです。契約は有効なiframeを要求します。命令を出さず拒否します。

MDN — Window.postMessage

受け入れ確認ノート

このガイドの基準に沿って観測を記録します。記録は認証ではありません。

自動保存されません。離れる前に書き出してください。

管理指標

指標測定対象最初のアクション
拒否した想定外ケース作用なしで拒否した異常ケース / 実行した異常ケースorigin、ウィンドウ、状態を記録
完了した許可通信完了した正常シナリオ / 試した正常シナリオ受信と確認済み作用を区別

よくある間違い

    よくある質問

    event.origin確認だけで十分ですか？

    いいえ。ウィンドウ、構造、状態も確認します。要求の権限はサーバーで確認します。

    公式参照文献

    参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。

    参照資料の確認日 .

    さらに詳しく調べる

    すべてのガイドサービスを見る

    関連分析