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

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

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

ここ数年、当社の方に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等）を指定し、ブラウザが取得したリソースのハッシュ値と照合することで、改ざんの有無を検証し、不一致時に実行を遮断する仕組みです。

Subresource Integrity（SRI）の完全性検査に失敗した場合、ブラウザは対象のJavaScriptやCSSを実行・適用せず、ネットワークエラーとして扱います。
また、対象のscript要素やlink要素ではerrorイベントが発生します。

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

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

なお、Content Security Policy（CSP）とSubresource Integrity（SRI）とは、いずれもブラウザ側で動作し、外部リソースに起因する攻撃リスクを低減できるセキュリティの仕組みである点が共通しています。
CSPが「どこから読み込むか」「実行を許可するか」を制御するポリシー型の仕組みであるのに対し、SRIは「取得した内容が正しいか」をハッシュ照合で検証する完全性確認の仕組みです。

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

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

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

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

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

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

なお、HTMLがHTTPで配信されている場合、通信経路上の攻撃者は外部リソースだけでなく、HTML内のハッシュ値を書き換えたり、integrity属性そのものを削除したりできることから、SRIを中間者攻撃への補完策として機能させるためには、integrity属性を記載したHTML自体がHTTPSで安全に配信されている必要があります。

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

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

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

Subresource Integrity（SRI）は、取得した外部リソースのハッシュ値を照合し、不一致の場合に実行・適用を拒否することで改ざんを遮断する仕組みですが、integrity属性による通常の完全性検査だけでは、ハッシュ不一致を管理者や監視サーバーへ直接通知することはできません。

前述のように、Subresource Integrity（SRI）の完全性検査に失敗した場合、ブラウザは対象のJavaScriptやCSSを実行・適用せず、ネットワークエラーとして扱います。
また、対象のscript要素やlink要素ではerrorイベントが発生します。

そこで、SRIによる読込み失敗を監視するためには、対象要素のerrorイベントをファーストパーティの監視基盤へ記録するとともに、重要機能の外形監視や、配信ファイルに対する独立したハッシュ監視を併用します。
また、errorイベントだけでは、SRIのハッシュ不一致、CORSエラー、404エラー、CDN障害などを区別できないため、原因調査時には配信状態と実際のファイルのハッシュ値を確認する必要があります。

なお、対応ブラウザでは、Integrity-Policy-Report-OnlyやIntegrity-PolicyとReporting APIを利用することで、integrity属性が設定されていないリソースや、SRIを適用できないno-corsリクエストを検出・制御できます。
ただし、これはSRIのハッシュ不一致そのものをCSPレポートとして収集する機能ではなく、ブラウザごとに実装状況も異なるため、導入前の検証が必要です。

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

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

このような理由から、SRIは外部リソースを経由した攻撃を防御する仕組みとして活用されます（内部リソースの改ざん対策は別途WAFや改ざん検知で行う必要があります）。ただし、外部リソースのうち、Webページとは異なるオリジンから配信されるリソースにSRIを適用する場合は、CORSへの対応も必要です。

前述のように、外部CDNなど、Webページとは異なるオリジンから配信されるリソースにSRIを適用する場合は、CORSに対応した配信が必要です。

一般的には、script要素やlink要素にcrossorigin="anonymous"を指定し、配信元のCDNがAccess-Control-Allow-Originヘッダーを返すようにします。

認証情報を必要としない一般公開リソースでは、Access-Control-Allow-Origin: *が使用されることがあります。

配信元がCORSに対応していない場合や、Access-Control-Allow-Originヘッダーが適切に設定されていない場合には、SRIのハッシュ値が正しくても、ブラウザはクロスオリジンのリソースの読み込みを拒否します。
そのため、事前にCDNやWebサーバーのレスポンスヘッダーを確認する必要があります。

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

また、外部リソースを更新するたびに、ハッシュ値の生成やHTMLへの反映をすべて手作業で行う運用では、ハッシュ値の更新漏れや転記ミスにより、更新後の正規ファイルが読み込めなくなるおそれがあります。
そのため、ハッシュ値の生成とHTMLへの反映は自動化することが推奨されます。

なお、ビルドのたびに外部CDN上の最新ファイルを取得し、その内容を無条件で正しいものとしてハッシュ化する運用は避ける必要があります。
外部リソースを更新する際は、バージョン変更、変更内容および脆弱性情報の確認、承認済みファイルからの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対象外にせず、スクリプトが持つ権限、取り扱う情報、内容の固定可否、配信元の仕様を基準に適用範囲を判断する。
　　固定可能な外部JavaScript・CSSは原則としてSRIの適用対象とし、対象外とする場合は理由と代替対策を記録する。
②　SRIを適用する外部リソースはバージョンを固定し、承認済みのファイルからハッシュ値を生成する。
　　更新時には変更内容の確認、ハッシュ値の更新、ステージング環境での動作テストを実施する。
③　CDN障害やSRI検査失敗に備えて代替経路を設ける場合は、信頼できる自社配信ファイル、または承認済みファイルと同一内容の別CDNを使用する。
　　別CDNを利用する場合も同じSRIハッシュで検証し、未検証のURLへ無条件で切り替える実装は避ける。
④　script要素やlink要素のerrorイベント、重要機能の外形監視、配信ファイルの独立したハッシュ監視を組み合わせて、リソース読込み失敗を検知する。
　　対応ブラウザでは、SRI属性の設定漏れを検出する目的でIntegrity-Policy-Report-Onlyの利用も検討する。

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

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

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