【2026年版】Subresource Integrity（SRI）とは｜設定と注意点

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は、Subresource Integrity（サブリソース完全性、SRI）の設定と注意点についてまとめたもので、2026年2月27日に執筆しています。

ここ数年、当社の方にContent Security Policyの設定とセットで、Subresource Integrityの設定に関するご相談、ご依頼が増えてきています。
※Content Security Policyについては、「Content Security Policyとは｜設定と注意点」を参照してください。

そこで、この記事では、企業のWeb担当である皆様に向けて、Subresource Integrityの設定と注意点をご案内したいと思います。

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

Subresource Integrity（サブリソース完全性、SRI）は、外部CDNなどから読み込むJavaScriptやCSSなどのリソースについて、<script>や<link>タグに integrity 属性でハッシュ値（SHA-256等）を指定し、ブラウザが取得したリソースのハッシュ値と照合することで、改ざんの有無を検証し、不一致時に実行を遮断する仕組みです。

これにより、外部CDN上のJavaScript・CSSの改ざんを検知し、不一致時に実行を遮断できる他、サプライチェーン攻撃のリスクを低下させ、被害を軽減することが可能になります。

Subresource Integrityは、設定していないから脆弱性があるというものではありませんが、防御を多層化するための補完的な仕組みとして有効です。

なお、Content Security Policy（CSP）とSubresource Integrity（SRI）とは、いずれもブラウザ側で動作し、外部リソースに起因する攻撃リスクを低減できるセキュリティの仕組みである点が共通しています。
CSPが「どこから読み込むか」「実行を許可するか」を制御するポリシー型の仕組みであるのに対し、SRIは「取得した内容が正しいか」をハッシュ照合で検証する完全性確認の仕組みです。
実務的には、両者を併用することで多層防御を強化しつつ、CSPのreport機能を通じてSRI違反イベントを収集することで可視化も実装していくことになります。

サプライチェーン攻撃とは、最終的な攻撃対象そのものではなく、ソフトウェア開発や配信の過程に関わる第三者（ライブラリ提供サーバー、CDNなど）を侵害し、正規の配布経路を通じて不正コードを混入させる攻撃手法です。

Subresource Integrityを適切に設定すると、事前に指定したハッシュ値と取得したリソースのハッシュをブラウザが照合し、不一致の場合は実行・適用を拒否することから、配信元サーバー内のリソースが改ざんされようと、CDNのキャッシュが改ざんされようとも、内容が変わっていればブラウザ側で不正コードの実行を防止できるため、被害拡大の抑止につながります。

このように、SRIは攻撃そのものを防ぐ技術ではありませんが、正規の配信経路を悪用する攻撃に対して最終実行段階でブロックできるという点で、サプライチェーン攻撃に対する補完的な防御策として有効です。

中間者攻撃（Man-in-the-Middle Attack）とは、通信を行う当事者の間に攻撃者が介在し、通信内容を盗聴・改ざん・差し替える攻撃手法です。
具体的には、公共Wi-Fi環境、侵害されたルータ、悪意あるプロキシ、証明書検証が不十分なHTTPS通信などを悪用し、配信途中のJavaScriptやCSSを書き換えるなどが該当します。

Subresource Integrityを適切に設定すると、事前に指定したハッシュ値と取得したリソースのハッシュをブラウザが照合し、不一致の場合は実行・適用を拒否することから、通信経路上でリソースが改ざんされた場合であっても、内容が変わっていればブラウザ側で遮断でき、不正コードの実行を防止できます。

このように、SRIは通信そのものを保護する技術（TLSなど）ではありませんが、通信途中で改ざんされた外部リソースの実行を最終段階でブロックできるという点で、中間者攻撃に対する補完的な防御策として有効です。

キャッシュポイズニング攻撃とは、CDNやリバースプロキシなどのキャッシュに不正なレスポンスを保存させ、利用者に改ざん済みコンテンツを配信させる攻撃手法です。
攻撃者はHTTPヘッダ操作やキャッシュキーの仕様を悪用し、本来とは異なる内容のJavaScriptやCSSを正規URL経由で配信させることで、不正コードを実行させようとします。

Subresource Integrityを適切に設定すると、事前に指定したハッシュ値と取得したリソースのハッシュをブラウザが照合し、不一致の場合は実行・適用を拒否することから、キャッシュに不正なコンテンツが保存・配信された場合でも、内容が改ざんされていればブラウザ側で遮断でき、不正コードの実行を防止できます。

このように、SRIはキャッシュシステムそのものを保護する技術ではありませんが、キャッシュ経由で配信された外部リソースの完全性を最終段階で検証できるという点で、キャッシュポイズニング攻撃に対する補完的な防御策として有効です。

Subresource Integrity（SRI）は、取得した外部リソースのハッシュ値を照合し、不一致の場合に実行・適用を拒否することで改ざんを遮断する仕組みですが、SRI自体には管理者へ通知する機能やサーバーへ自動通報する機能はなく、単体では攻撃試行を直接可視化することはできません。

一方で、Content Security Policy（CSP）を有効化し、report-uriやreport-to(現在はreport-toが推奨されています)を設定することで、SRI違反をCSP違反レポートとして収集することができます。
これにより、改ざんの試行や異常な配信の発生をログとして把握でき、攻撃傾向の分析や早期対応につなげることができます。

このように、SRIは単体では可視化機能を持ちませんが、CSPのレポート機能と組み合わせることで、改ざん試行を検知・記録し、攻撃傾向の可視化を実装することが可能となります。

Subresource Integrity（SRI）は、ブラウザが取得したリソースの内容（バイト列）からハッシュ値を計算し、HTMLに記載されたintegrity属性のハッシュ値と一致するかを照合する仕組みですので、理論上は外部リソースの完全性だけでなく内部リソースの完全性についてもチェックできます。

しかしながら、内部リソースについては、仮に改ざんされているなら、基本的にはサーバーが侵害されている状態ですので、HTML側のintegrityも同時に書き換えられる可能性が高いため、防御効果は（完全に無意味とはいえないまでも）限定的となってしまいます。

このような理由から、SRIは外部リソースを経由した攻撃を防御する仕組みとして活用されます（内部リソースの改ざん対策は別途WAFや改ざん検知で行う必要があります）。

Subresource Integrity（SRI）は、配信されるリソースの内容（バイト列）と完全に一致するハッシュ値を前提とするため、latest指定のように常に最新バージョンのファイルを読み込むように設定すると、integrity属性に記載したハッシュ値とズレが生じ、正規ファイルでも読み込みが拒否される可能性があります（特に、CDNでlatest指定を使っているケースがよくあります）。
そのため、外部リソースは固定バージョンを指定し、更新時にはハッシュ再生成を含めて適切に反映する運用とする必要があります。

また、HTMLをビルドする際に、毎回手動でハッシュ値を設定する運用では、ハッシュ値の更新漏れにより正規ファイルの読み込みが拒否される可能性があります。
そのため、HTMLをビルドする際には、自動で外部リソースのハッシュを算出してHTMLへ反映する仕組みを組み込んでおくことが推奨されます。

このように、SRIを安全に運用するためには、「バージョン固定」と「ビルド時のハッシュ自動生成」を前提に設計・実装することが重要です。

Subresource Integrity（SRI）は、ブラウザが取得したリソースの内容（バイト列）からハッシュ値を計算し、HTMLに記載されたintegrity属性のハッシュ値と一致するかを照合することから、同じURLであってもリクエストのたびにレスポンス内容が変わるリソースでは、ハッシュ値が毎回変化してしまい、結果的に正規の配信であってもハッシュ不一致となり、当該リソースが適用・実行されず、画面表示の崩れや機能停止につながる可能性があります。

一般的なCMSでも、プラグインや最適化機能によりJavaScriptやCSSが動的に結合・圧縮されたり、ユーザーごとに内容を差し替えたりするケースがあります（例：A/Bテスト用の差し替え、利用者属性に応じたスクリプト出し分け、トラッキング用の動的挿入、リクエストごとに異なるクエリ結果を含むJS生成など）。
このような動的リソースにSRIを付与すると、意図せず読み込み失敗を頻発させるため、原則として適用対象から除外し、固定バージョンの静的リソース（外部CDNのライブラリ等）に限定して運用する必要があります。

Subresource Integrityは、ブラウザが取得したリソースの内容（バイト列）を基にハッシュ値を計算し、HTMLに記載されたintegrity属性のハッシュ値と一致するかを検証することから、CDNの最適化機能によって配信時に内容そのものが書き換えられる場合、ハッシュ値の不一致によりリソースが適用・実行されなくなる可能性があります。

例えば、CDN側でHTML、CSS、JavaScriptの最小化（コメント除去、不要な空白削除などのminify化）、CSSの並び替え、JavaScript書き換え、画像の最適化、あるいは自動的な結合などが有効になっていると、オリジンのファイルと配信ファイルの内容が一致しなくなることがあります（CDNが転送効率を上げる目的で行うgzipやbrotliなどの転送時圧縮は、復号後の内容が同一であれば基本的には問題になりません）。

そのため、SRIを利用する場合は、対象リソースに対してCDNの書き換え系最適化を無効化する、もしくは書き換えが起きない配信経路に限定するなど、配信内容の同一性を担保する設計が重要です。

このように、Subresource Integrity（SRI）の設定は、セキュリティ強化に有効ですが、一方で可用性（サービス継続性）に影響する可能性があります。

特に影響が大きい典型例としては、ログイン画面や管理画面が特定のJavaScriptに強く依存している場合に、当該スクリプトが読み込めないだけで認証フローが動作せずログイン不能になることが挙げられます。
また、決済代行会社のJavaScript（カード入力フォーム、3Dセキュア、トークナイゼーション等）が読み込めない場合、決済不能となり直接的な売上損失につながるケースも考えられます。
さらに、エラートラッキングや監視タグが読み込めないことで障害検知が遅れる、同意管理（CMP）やCookie制御が動かず法令対応に影響するといったケースも起こりえます。

このためSRIを導入する際は、「どの外部リソースが止まると致命的か」を事前に棚卸しを行った上で、影響度に応じて以下のようなフォールバック設計を検討することが重要です。
①　重要度の低い外部ライブラリはSRI対象から意図的に外す。
②　重要な外部リソースは固定バージョン化し、更新手順とハッシュ再生成を厳格に運用する。
③　CDN障害やSRI不一致を想定した代替経路（別CDNや自社配信への切替）を用意する。
④　CSP reportやフロント監視（Sentry等）でSRI違反を検知して即時対応できる体制を整える。

このように、Subresource Integrity（SRI）の設定費用は、単に<script>や<link>タグへintegrity属性を追加するだけの対応でよいのか、それとも運用設計まで含めた仕組みとして構築するのかによって大きく変わります。
費用を左右する主な要素は、対象とするリソースの範囲、運用方式（手動管理か自動化か）、CMSやインフラ構成の複雑さ、可用性や監視設計の有無となります。

Subresource Integrity（SRI）の設定は、セキュリティ強化に有効であり、近年導入に関するご相談も増えてきています。

しかしながら、前述のようにSRIの設定は調査・設計の上で、慎重に実施をする必要がある作業であり、またWebサイトのセキュリティに対する総合的な知見が求められることから、ご契約されているWeb制作会社では対応できないと回答されるケースもあるようです。