このドキュメントでは、Adobe Experience Platform Launch でサブリソースの整合性(SRI)がどのようにサポートされているかについて説明します。
最新の Web サイトは、Web 上の様々な場所から画像、コンテンツ、スクリプトを参照することで構築されています。SRI を使用すると、要求されたファイルの内容が予期せず変更されていないことをブラウザーが確認できます。
これらの使用例はいずれも優れていますが、SRI はコンテンツセキュリティポリシー(CSP)とは異なります。CSP は、信頼されているソースからのファイルのみを Web サイトで許可するようにします。SRI はさらに踏み込んで、これらのファイルのコンテンツが想定どおりであることを確認します。
SRI の詳細については、MDN Web ドキュメントを参照してください。
SRI の検証プロセスの概要は次のとおりです。
integrity
属性に配置されます。integrity
属性を確認すると、ブラウザーはそのリソースを要求し、独自のバージョンの暗号化ハッシュを別々に生成します。integrity
ハッシュと、生成されたハッシュを比較します。一致する場合は、アセットが許可されます。一致しない場合、アセットはブロックされます。タグ管理システム(TMS)として、Platform Launch は単一の <script>
要素(埋め込みコード)を使用してページに読み込む、コンパイル済みの JavaScript ライブラリビルドを提供します。TMS が提供する動的な機能は、スクリプトの内容を動的にスワップアウトすることで実現され、他の変更をおこなう必要はありません。
ただし、スクリプトコンテンツが変更されると、それらのコンテンツの暗号化ハッシュも変更されます。したがって、TMS で SRI を機能させる唯一の方法は、新しいビルドを公開するのと同時に埋め込みコードを更新することです。多くの場合、これによって、最初から TMS を使用する主な目的がなくなります。
Platform Launch に対する次善のセキュリティオプションは、コンテンツセキュリティポリシーを実装することです。詳細については、 Platform Launch の CSP ガイドを参照してください。
ライブラリビルドで SRI を引き続き使用したい場合は、自己ホスティングを使用する必要があります。アドビ管理ホスティングを使用している場合、新しいビルドコンテンツが埋め込みコードの integrity
属性と一致しない場合、SRI を使用するにはある程度の時間をかける必要があります。
埋め込みコードの更新プロセスを自動化する際の一般的な手順を以下にまとめます(複雑さはサイトの構造によって異なります)。
integrity
属性が新しいハッシュに更新され、参照先のビルドが同じデプロイメントの一部として更新されていることを確認します。この方法は、メインのビルドにのみ対応しています。このファイルには、存在する可能性のある小さいファイルは含まれません。
このドキュメントでは、Platform Launch での SRI の使用に関する制限事項を示します。また、この制限事項にかかわらず、ライブラリビルドのデプロイメントに SRI を統合するために必要な手順についても説明します。まだ読んでいない場合は、別のセキュリティオプションについて、 Platform Launch の CSP に関するガイドを読むことを強くお勧めします。