サブリソースの整合性は実際にどのように役立ちますか？
サブリソースの整合性により、基本的に、ダウンロードしようとしているリソースが有効であることを知ることができます。これは、そのコンテンツのハッシュが予想と一致するためです。
しかし、これは私がすでに信頼され検証されたコードで実行していることを前提としています。ハッカーがリソースを提供するサーバーを危険にさらした場合、ルートリソースを自分の悪意のあるコードのハッシュに置き換える（または完全性チェックを完全にバイパスする）ことができます。
では、サブリソースの整合性チェックはどのように役立ちますか？そして、クライアントはどのようにしてルートリソースを検証しますか？
サブリソースの整合性とは、Webアプリケーションの独自のコードを変更から保護することではありません。 SRIが意図することは 目標の説明 から見ることができます：
サードパーティサービスの侵害は、スクリプトを含むすべてのサイトの侵害を自動的に意味するものではありません。
したがって、それはあなたの管理下にないサイトにあるリソースの使用を保護することです。サードパーティのサイトからのコードが含まれている場合でも、SRIはある程度の制御を返します。可用性は提供されませんが、整合性、つまりサードパーティ（またはこのパーティを乗っ取ったハッカー）による不要な変更に対する保護が提供されます。
JQueryを中心に構築されたサイトがあるとします。 jQueryをダウンロードしてコピーを使用するのではなく、クライアントのブラウザーのキャッシュを利用してCDNのバージョンを使用します。これは、1つのサイトがCDNバージョンを使用する場合、キャッシュされ、同じバージョンを使用するすべてのサイトにメリットがあるため、毎回同じファイルをダウンロードする必要がないため機能します。
ある日、誰かがCDNサーバーに侵入し、JavaScriptファイルを変更されたバージョンに置き換えて、すべてのキーストロークを攻撃者のサーバーのどこかに送信します。そして、そのスクリプトを使用するすべてのサイトが影響を受けます。
ここに Subresource Integrity-SRI と入力します。第三者が検出されない外部リソースを変更するのを防ぎます。外部リソースでSRIを有効にしている場合、クライアントブラウザーはハッシュが一致しないリソースをロードしません。
その後、ルートリソースを自分の悪意のあるコードのハッシュで簡単に置き換えることができます
あんまり。 SRIは、ユーザーが制御しないサードパーティのスクリプトの変更からサイト（ユーザーが制御するコード）を保護します。コードへの攻撃はSRIで保護されていません。攻撃者がサードパーティのスクリプトとを変更した場合、攻撃者はあなたのサイトのみを変更して同じことを行えるためです。トラブルの少ないサイト。結局のところ、サイトを攻撃する方が、Akamai、CloudFlare、Google、Microsoftを攻撃するよりも簡単です。