postMessageの送受信元を限定するには？targetOriginの固定とevent.origin検証・診断基準

postMessageの送受信元を限定するとは

postMessageの送受信元を限定するとは、window.postMessage() でデータを送るときに宛先オリジンを具体的に指定し、受け取るときに送信元オリジン（event.origin）とメッセージの構造を検証して、想定外の相手とのやり取りを拒否することです。

window.postMessage() は、異なるオリジンのウィンドウやiframeの間で安全にデータをやり取りするためのブラウザAPIです。自治体サイトでは、埋め込み地図、チャットボット、予約システム、アンケート、動画プレーヤー、翻訳ウィジェットなどのiframeと親ページの間で使われます。

安全に使うには、送信時に宛先オリジンを具体的に指定し、受信時に送信元オリジン（event.origin）とメッセージの構造を検証する必要があります。セキュリティAIチェッカーのこの項目は、トップページのHTMLに含まれるインラインスクリプトから、ワイルドカード送信や、オリジン検証のない受信処理の兆候を静的に検出します。

postMessageの送信側と受信側で何を限定すべきか

送信側：targetOriginを固定する

otherWindow.postMessage(message, targetOrigin, [transfer]);
otherWindow.postMessage(message, { targetOrigin, transfer });

targetOrigin は、受け取る側のウィンドウが現在どのオリジンの文書を表示しているべきかを指定します。"*" を指定すると、相手ウィンドウが別サイトへ遷移していても送信されます。MDNは「宛先文書の場所が分かっている場合は * ではなく具体的な targetOrigin を常に指定すること」とし、悪意あるサイトがウィンドウの遷移先を知らないうちに変更し、送信データを横取りできると説明しています。

受信側：event.originと構文を検証する

message イベントは、どのオリジンのページからでも送られてきます。受信側は次の点を確認する必要があります。

1. event.origin が許可したオリジンと完全一致するか（indexOf や endsWith による部分一致は https://city.example.lg.jp.evil.example のような回避を許す）
2. 必要に応じて event.source が想定したiframeの contentWindow か
3. event.data の型・構造が想定どおりか（ASVS V3.5.5は構文不正なメッセージの破棄も要求）
4. 受け取った値を innerHTML や eval に渡さない（OWASP HTML5 Security Cheat SheetとWSTG-CLNT-11が、DOM型XSSの典型として注意を促しています）

MDNはさらに、他サイトからのメッセージを受け取る必要がないなら message リスナーを登録しないことが最も確実な対策だとしています。

postMessageについてよくある誤解

• 「iframeの中身は自分たちが用意したものだから * でよい」：iframeやポップアップのウィンドウは別サイトへ遷移させられる可能性があり、そのときに送ったデータが漏れます。
• 「event.origin を参照していれば安全」：ログ出力のために参照しているだけで比較していない、部分一致で比較している、という実装もあります。
• 「Workerの onmessage も同じ問題」：Dedicated Workerとのメッセージは同一オリジンのスクリプト間通信であり、ウィンドウ間メッセージとはリスクの性質が異なります。

postMessageの送受信元を限定の診断基準（セキュリティAIチェッカー）

取得対象

• 入力URLのリダイレクト後の最終URLのHTML本文（最大2MB）を文字列として解析します。
• 外部JavaScriptファイル（ベンダーのウィジェット本体など）は取得しないため、その中の実装は判定に含まれません。静的な文字列パターンによる「兆候」の判定であり、実際の動作を確認したものではありません。

判定に使う4つの兆候

判定条件

• 静的解析では、実際に機密データを送っているか、比較が完全一致かまでは判断できないため、問題の兆候があっても×（fail）ではなく△（要確認）とします。
• 根拠欄には、ワイルドカード送信（「postMessageの送信先にワイルドカードを使う兆候があります。」）か、受信時の検証欠如（「message受信処理にevent.origin検証の静的兆候がありません。」）かを区別して表示します。
• 重大度はhigh、重みは3です。

自治体サイトでの判定例

検出の限界

• if (e.origin.indexOf("example.lg.jp") > -1) のような部分一致の比較も、e.origin を参照しているため「検証の兆候あり」と扱われます。部分一致は回避可能な不十分な検証であり、○でもコードレビューで比較方法を確認してください。
• 受信処理を外部JSファイルに置いている場合は検出されません。
• ws.onmessage = ...・worker.onmessage = ... のようなプロパティ代入は、WebSocketやWeb Workerの受信処理とみなして数えません。一方 addEventListener("message" は登録先がウィンドウかどうかを区別しないため、WebSocket、Web Worker、EventSource（Server-Sent Events）、BroadcastChannelに対する登録（例: ws.addEventListener("message", ...)）も「受信処理」と数え、ウィンドウ間メッセージを使っていないページでも、オリジン検証の兆候がなければ△になります。Worker内スクリプトの素の onmessage = も同様です。この場合は根拠欄が「message受信処理にevent.origin検証の静的兆候がありません」となるので、該当コードがウィンドウの message イベントかどうかを目視で確認してください。
• const { origin, data } = event; のような分割代入で取り出し、文字列リテラル以外（定数や配列）と比較している場合は、検証していても兆候として認識されず△になることがあります。

postMessageの送受信元を限定しないとどんなリスクがあるか

• 情報漏えい：ワイルドカード送信で、入力途中のフォーム内容、利用者識別子、トークンなどを送っている場合、相手ウィンドウを攻撃者のページへ遷移させることでデータを受け取られます。
• DOM型XSS：オリジン未検証の受信処理が event.data をHTMLとして挿入したり、URLとして遷移に使ったりすると、攻撃者のページからメッセージを送り込むだけで、自治体サイト上でスクリプトを実行される可能性があります。
• 偽の操作指示：「ログアウトせよ」「この画面へ遷移せよ」といった制御メッセージを受け付ける実装では、外部から画面遷移や状態変更を引き起こされます。
• 埋め込み元のなりすまし：自治体サイトのウィジェットが他サイトに埋め込まれる場合、受信側で送信元を確認しないと、任意のサイトから操作されます。

innerHTML や eval など危険なAPIの使用そのものは「危険なJavaScript APIの兆候」でも確認しています。

postMessageの送受信元を限定する実装方法・対策

1. 送信側：宛先を固定する

const MAP_ORIGIN = "https://map.example-vendor.jp";
const frame = document.getElementById("map-frame");
frame.contentWindow.postMessage({ type: "setCenter", lat: 35.0, lng: 135.0 }, MAP_ORIGIN);

// iframe側から親へ送る場合も親のオリジンを固定
parent.postMessage({ type: "resize", height: document.body.scrollHeight }, "https://www.city.example.lg.jp");

2. 受信側：完全一致の許可リストと構造検証

const ALLOWED = new Set(["https://map.example-vendor.jp", "https://reserve.example-vendor.jp"]);

window.addEventListener("message", (event) => {
  if (!ALLOWED.has(event.origin)) return;                // 完全一致
  const frame = document.getElementById("map-frame");
  if (event.source !== frame.contentWindow) return;      // 送信元ウィンドウも確認
  const data = event.data;
  if (typeof data !== "object" || data === null || data.type !== "resize") return;
  const h = Number(data.height);
  if (!Number.isFinite(h) || h < 0 || h > 10000) return; // 値の範囲検証
  frame.style.height = `${h}px`;                          // innerHTMLは使わない
});

文字列を表示する必要がある場合は textContent を使います。

3. 不要なリスナーを置かない

過去のキャンペーンページの名残など、使っていない message リスナーは削除します。CMSのテンプレートに共通で入っている場合は、必要なページだけに限定します。

4. ベンダー製ウィジェットの確認

外部JSの中身はこの診断では見えません。チャットボットや地図などの導入時には、ベンダーに「送信先オリジンの固定」「受信時のorigin完全一致検証」「受信データのHTML挿入の有無」を仕様書や回答書で確認してください。

5. 併用する防御（サイトを壊さない範囲で）

Content-Security-Policy: frame-src https://map.example-vendor.jp https://reserve.example-vendor.jp; frame-ancestors 'self'

frame-src で埋め込めるiframeの配信元を限定し、frame-ancestors で自サイトを埋め込めるサイトを限定します。外部から埋め込まれることを前提とするページでは frame-ancestors に埋め込み元を追加してください。既存の埋め込みを洗い出したうえで、Report-Onlyから始めます。埋め込む側のiframeの制限は「外部iframeのsandbox」、埋め込まれる側の制限は「クリックジャッキング対策」で確認します。

6. 確認方法

curl -s https://www.city.example.lg.jp/ | grep -n -E 'postMessage|addEventListener\(\s*["'"'"']message|onmessage'

ブラウザの開発者ツールで、Sourcesパネルのイベントリスナーのブレークポイントにある「message」を有効にし、受信処理がoriginを比較しているかを実際に確認します。異なるオリジンのテストページから postMessage を送り、無視されることを確かめるとより確実です。修正後はセキュリティAIチェッカーで再診断し、根拠欄の表示が変わったことを確認してください。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.5.5）
• OWASP WSTG-CLNT-11 Testing Web Messaging
• MDN Window: postMessage() method
• OWASP HTML5 Security Cheat Sheet

「postMessageの送受信元を限定」と関連する診断項目

• 危険なJavaScript APIの兆候high
• 外部iframeのsandboxmedium
• クリックジャッキング対策high
• 別タブリンクのnoopenermedium
• Mixed Contentがないhigh
• WebSocketをWSSで暗号化high
• 廃止されたクライアント技術を使用していないhigh
• 外部JavaScript依存数medium