さまざまなiframe間でHTML5メッセージングAPIを介してアクセストークンを共有しても安全ですか？
私はiframeを介して他の3つのWebサイトを埋め込むメインWebサイトを持っています（ユーザーインターフェイスでさまざまな機能を提供するレガシーシステム）。現在、ユーザーはすべて同じ認証サーバーを使用しているにもかかわらず、各システムで認証を行う必要があります。ユーザーフレンドリーにするために、HTML5メッセージングAPIを使用してさまざまなiframe間でアクセストークンを共有することを考えていましたが、このアプローチがセキュリティの観点から実行可能かどうか疑問に思いましたか？
postMessage API は、クロスオリジンリソースシェアリングメカニズムの一部としてのクロスドメイン通信用に設計されています。
HTML5で導入されたWindow.postMessage（）メソッドを使用すると、異なるオリジンで実行されているJavaScriptコードが双方向で相互に通信できます。このAPIは、iframeとその親ドキュメント間の通信に使用できます。同様に、HTMLページと子ウィンドウでメッセージを交換するために使用できます。たとえば、ユーザーがビデオを一時停止したときに親フレームに通知する埋め込みサードパーティビデオなどです。
従来のセキュリティ規則は、postMessage（）を使用するアプリケーションにも適用されます。この方法を使用して認証情報を共有することを計画していますが、実装時に基本的な入力検証規則に従っている場合は問題ありません。
認証トークンをブロードキャストしないでください：シナリオには、共通のトークンにアクセスする必要がある複数の異なるパーティが含まれています。すべてのiframeがアクセスできるように、認証情報をブロードキャストしたくなるかもしれません。これにより、トークンへの不正アクセスが発生する可能性があります。したがって、postMessage（）呼び出しは常にターゲットOriginを指定する必要があります。
常にメッセージの発信元を検証する：メッセージが有効かつ予期された発信元から受信されたことを検証する必要があります。 Originの検証後のみ、アプリケーションロジックでメッセージを使用して続行する必要があります。アプリが悪意のあるドメインによって攻撃された場合を想像してみてください。メッセージの発信元を検証しないと、スクリプトが挿入される可能性があります。
さらに、承認サーバーとの信頼関係によっては、送信元のOriginが検証されたら、トークン自体を検証することもできます。
PostMessage（）APIセキュリティの詳細な分析といくつかのコードスニペットの例については、my Blog を参照してください。
最新のブラウザがCookieとドメインのアクセス制御で従う規則について読むことができます： RFC6265
多くの理由でIFrameは推奨されていません（SEOのような、Googleのインデックス作成、セキュリティ、...）。
デフォルトのCookieドメイン設定を使用する新しいバージョンのブラウザは、このテーマでは99％安全です。ただし、IFrame（およびブラウザー）の履歴における最も多くのセキュリティリスクは、CSRFとXSSに関するものでした。したがって、CSRFトークンとXSSフィルタリングメソッド+ Cookieドメイン構成を修正してサイトを保護している場合、脆弱なブラウザーを使用していても、IFrameを使用することはほぼ安全です。