目次
外部のCDNやサービスからJavaScriptを読み込むことは、サイトのコードの一部を外部の配信へ委ねることでもあります。配信元のURLが想定どおりでも、内容が承認したものと同じかは別の問題です。SRIは、この内容の一致をブラウザーで確かめる仕組みです。
本記事は2026年10月18日にMDNとOWASPの一次資料を確認した実務解説で、特定の侵害事件の速報ではありません。既存のCSPやnpmの供給網の記事とは分け、ブラウザーが取得するファイルの内容と、その更新運用を中心に扱います。導入手順は本サイトの提案です。
スポンサーリンク
URLを許すことと内容を照合することは違う
SRIでは、HTMLのintegrity属性などに期待するハッシュを指定します。対応するリソースを読み込む際に、ブラウザーは取得した内容を照合し、一致しなければ利用を拒否します。MDNはscript要素と、対応する用途のlink要素での利用を説明しています。
CSPで配信元を限定しても、その許可先で配られるファイルの内容が期待したものかは、別に確認する必要があります。反対にSRIで一致しても、そのスクリプトの処理自体が業務上安全だと保証されるわけではありません。
本サイトの提案は、配信元と内容、実行させる必要性を別々に判断することです。不要なタグを削除する判断は、ハッシュを付ける対策より先に行える場合があります。
まずページごとの外部リソースを一覧にする
トップページだけでなく、ログイン、申込、決済、管理画面など、機密性が異なる場所で何を読み込むかを確認します。HTMLへ直接書いたタグに加え、タグマネージャーや外部スクリプトが後から追加する読み込みも対象です。
本サイトの提案として、所有者、用途、配信元、版、更新の頻度、削除した場合の影響を記録します。管理画面へ全ページ共通の解析タグを付ける必要があるかなど、機能ごとに見直してください。
ネットワークの記録を見る際も、実際の利用者の秘密や個人情報を無差別に共有しないようにします。テスト用のアカウントと架空データで代表の操作を行い、読み込みの経路を把握します。
スポンサーリンク
ハッシュは承認する内容から作る
配信先から今取得したファイルのハッシュを無条件に採用すると、内容が変わっていても、それを新しい正解として登録する場合があります。ハッシュの計算は一致を示すための処理であり、内容を承認する手順の代わりではありません。
本サイトの提案は、公式に配布された対象の版や、検証したビルド成果物を確認し、その承認済みのファイルからハッシュを作ることです。どの版とどの内容を採用したかをレビューできる形で保存します。
自動化する場合も、依存関係の更新と承認の仕組みを組み合わせます。本番の読み込みに失敗したら配信先の内容を取得してハッシュを自動で合わせる、という復旧は、変更を検知する役割を失わせるので避けます。
別オリジンからの読み込みではCORSも確認する
MDNは、別オリジンのリソースにSRIを使う場合、CORSの条件が必要であると説明しています。HTMLの属性だけでなく、配信側の応答が、その読み込みを認める構成になっているかを確認します。
一般的な公開の静的リソースではcrossorigin="anonymous"を使う例がありますが、属性を機械的に追加するだけで終わらせないでください。実際のリソースの応答と、利用するブラウザーでの読み込みの結果を照合します。
CORSの設定変更が必要な場合も、APIの認証や非公開データを公開する話とは分けます。SRIを動かすために、関係のない機密APIへ広い許可を追加するような変更は避けます。
出典：OWASP Third Party JavaScript Management Cheat Sheet。
スポンサーリンク
版と内容が変わらないURLを運用に組み込む
同じURLの内容が頻繁に変わるリソースでは、正当な更新でもSRIが不一致を検知します。更新される内容へ追従したいのか、承認した版を固定したいのかを決め、サービスの配布方針と両立するかを確認します。
本サイトの提案は、版を固定できるファイルでは、そのURLと内容、HTMLのハッシュを一つの変更として管理することです。ファイルだけ先に差し替え、古いHTMLが残る配布では、利用者の環境によって読み込みに失敗する場合があります。
CDN、HTMLのキャッシュ、段階公開の順序も検討します。新旧の版を提供する期間と、どこまで戻せるかを定義します。障害時にintegrityを削除してとりあえず読み込ませる対応を、標準の復旧手順にしないようにします。
動的なタグを含む全体が自動で保護されるわけではない
SRIを付けた一つのファイルが、さらに別のスクリプトやデータを読み込む場合があります。最初のファイルが一致することから、後続のすべての取得内容まで承認済みだとは判断できません。
本サイトの提案として、動的な読み込みを含む依存関係を把握し、内容を固定できないサービスをどう扱うかを決めます。不要なら削除し、必要なら利用するページと渡すデータを減らすなど、能力を限定する方法を検討します。
別オリジンのiframeを使える構成でも、メッセージの送受信や許可する能力を別に設計する必要があります。SRI、CSP、分離した表示は、それぞれ守る境界が異なり、どれか一つで外部コードのリスクがなくなるわけではありません。
自己配信へ変えるなら更新の責任も引き受ける
外部ファイルを自分のサイトで配信すると、配信先への依存を減らせる場合があります。一方、利用条件を守ること、セキュリティ更新を取り込むこと、正しい版を維持することはサイト側の作業になります。
本サイトの提案は、コピーを置く判断と、保守する担当と期限を一緒に決めることです。外部のURLを消したことで、古いライブラリーが更新されないまま残る状態を避けます。承認した成果物の記録は、自己配信でも役立ちます。
HTMLそのものやビルド環境が改ざんされ、ファイルと期待するハッシュを一緒に変更された場合、SRIだけではその変更を見抜けません。コードレビュー、配布権限、依存関係の管理は別の対策として維持します。
障害の切り分けに必要な情報を用意する
SRIの不一致と、配信元へ接続できない障害、CORSの不備では原因が異なります。本サイトの提案は、利用するブラウザーの診断情報と、配布したHTMLの版、対象ファイルの版を対応付けられるようにすることです。エラーの件数だけで、外部配信が改ざんされたと断定しないようにします。
障害時に参照するファイルは、承認済みの成果物を基準に比較します。配信されたファイルの差を調べる場合も、運用者の通常のブラウザーで無条件に実行する必要はありません。検証環境で内容と配布経路を確認します。
古いHTMLを持つ利用者だけが失敗する場合は、キャッシュや配布の順序を調べます。重要な機能が使えない利用者へ、操作が完了したように見せないことと、安全な復旧方法を提供することを、リリースの基準へ含めます。
スポンサーリンク
タグの所有者が更新を説明できるようにする
外部タグを追加した部署と、実際のサイトの保守担当が異なる場合、更新の通知が届かないことがあります。本サイトの提案は、タグごとに業務上の所有者と技術的な保守担当を決め、継続する理由と変更の確認方法を共有することです。
契約が終わった機能や、試験で追加したタグが残っていないかも見直します。配信元が信頼できるかだけでなく、そのコードへページ内のどの情報を渡す必要があるかを確認します。SRIを付けられることは、機密なページへ置く理由にはなりません。
利用条件により自己配信ができない場合や、内容が可変で固定できない場合は、その制約を明記します。対策が使えない理由を記録し、削除や限定利用など別の判断へつなげることが、形式だけの導入を防ぎます。
リリース単位で正常な組み合わせを残す
ファイルのURL、承認した内容、ハッシュ、HTMLを一つの組み合わせとして記録すると、ロールバック時に対応する版へ戻しやすくなります。ハッシュだけを古く戻し、ファイルは新しいままという不整合を避けます。
試験では、新しい版を読み込む場合と、古いHTMLが残る場合を分けます。どちらを許すのかは配布方式によりますが、想定しない組み合わせで重要な画面が止まることを事前に発見できるようにします。更新の検知と運用の継続を両立するための確認です。
スポンサーリンク
不一致を使った試験と復旧を用意する
検証環境では、承認したファイルが読み込めることを確認した後、無害な変更を加えたファイルが拒否されることを確かめます。実際に悪意のあるコードを実行させる必要はありません。CORSの条件を満たす場合と満たさない場合も分けて確認します。
スクリプトが拒否された後、画面が途中の状態で止まらないか、重要な操作が誤って成功したように見えないかを調べます。読み込み失敗を検知する記録と、既知の安全な版へ戻す手順を用意します。
SRIは、内容が予期せず変わったときに止めるための仕組みです。その停止を事故としてすぐ無効化するのではなく、何が変わったかを確認してから復旧する運用と合わせることで、役割を保てます。
参考資料
以下の一次資料を2026年10月18日に確認しました。本文の仮想例と運用手順の提案は、資料の引用とは区別しています。
