Subresource Integrityとリソース改ざん検出

Subresource Integrity（SRI）は、外部から読み込む <script> や <link rel="stylesheet"> の中身が「期待したバイト列と一致するか」をブラウザに検証させる仕組みです。CDN やミラーが改ざんされても、配信されたファイルが事前に登録したハッシュと食い違えば実行・適用を拒否します。ここでは照合アルゴリズム、crossorigin が必須になる理由、複数ハッシュとキャッシュの相互作用を原理から見ていきます。

なぜハッシュ照合で改ざんを検出できるか

SRI は対象要素の integrity 属性に、アルゴリズム名-base64ダイジェスト という形式のメタデータを埋め込みます。ブラウザはリソースのバイト列をネットワークから受け取った後、実行・適用の直前に同じアルゴリズムでダイジェストを再計算し、属性値と完全一致するかを比較します。一致すれば通常どおり処理し、不一致ならリソースをネットワークエラーとして破棄します。

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

成立の根拠は暗号学的ハッシュの衝突困難性です。SHA-256／384／512 は、同じダイジェストを持つ別バイト列を現実的な計算量で見つけられないよう設計されています。したがって攻撃者が CDN 上のファイルを書き換えれば、ダイジェストはほぼ確実に変わり、照合で弾かれます。逆に言えば、SRI が守るのは「配信経路で中身がすり替わっていないこと（完全性）」であって、元のファイル自体が安全かどうか（出自・意図）は保証しません。

crossorigin が必須になる理由

SRI で最もつまずくのが crossorigin 属性です。クロスオリジンのリソースに SRI をかけるなら crossorigin は必須で、付け忘れると照合できずに読み込みが失敗します。理由はブラウザのオリジン分離にあります。

通常の <script src> はクロスオリジンでも取得できますが、その応答は opaque（不透明）応答 として扱われ、JavaScript からもブラウザ内部の検査からも中身（ボディのバイト列）を読めません。これは 同一オリジンポリシーとサイト分離の信頼境界 が、別オリジンのデータ漏洩を防ぐための原則的な制約です。中身が読めなければハッシュも計算できないため、SRI は成立しません。

そこで crossorigin="anonymous" を付けると、ブラウザはこの取得を CORS（オリジン間リソース共有） モードで行い、サーバーが Access-Control-Allow-Origin を返して明示的に共有を許可した場合にのみ、応答を不透明でなくします。これでブラウザはバイト列を読めるようになり、ハッシュ照合が可能になります。

crossorigin には anonymous と use-credentials があり、Cookie やクライアント証明書を CORS リクエストに乗せるかどうかが違います。CDN 上の公開ライブラリは通常 anonymous（資格情報を送らない）が適切です。

複数ハッシュとアルゴリズム選択

integrity には空白区切りで複数のダイジェストを並べられます。これは「どれか1つに一致すればよい」という OR ではありません。ブラウザは並んだものの中から最も強いアルゴリズムを選び、その1種類だけで照合します。

<!-- ブラウザは sha384 を選んで照合する。sha256 は無視される -->
<script src="https://cdn.example.com/lib.js"
        integrity="sha256-abc... sha384-def..."
        crossorigin="anonymous"></script>

強さの優先順位は sha512 > sha384 > sha256 です。同じアルゴリズムのダイジェストを複数並べた場合のみ、そのどれか1つに一致すれば許可されます。これはリソースの差し替え期（旧版と新版の両方が出回る移行期）に、両バージョンのハッシュを並記して切り替えを滑らかにするための仕組みです。

キャッシュ・プリロードとの相互作用

SRI の照合は毎回のリソース利用時に行われます。ブラウザがメモリキャッシュやディスクキャッシュ、あるいは HTTP キャッシュ からリソースを再利用する場合でも、保持しているバイト列に対して integrity を照合します。したがって、同じ URL でも integrity の値が変われば、キャッシュ済みの古い中身は不一致となり再取得が走ります。これがキャッシュバスティングと同様の「ハッシュ更新＝強制再検証」の効果を生みます。

プリロード（<link rel="preload"> や <link rel="modulepreload">）との組み合わせには注意が要ります。プリロードした応答を後続の <script> が再利用するには、両者の取得条件が一致していなければなりません。とくに crossorigin の有無が食い違うと、別々の取得として扱われ二重ダウンロードになります。SRI をかける本番の <script> が crossorigin="anonymous" なら、プリロード側にも同じ crossorigin を付けて取得条件を揃える必要があります。

SRI が守る範囲と守らない範囲

SRI はあくまで「登録済みハッシュと配信バイト列の一致」を検証する仕組みであり、万能ではありません。範囲を正確に押さえることが、過信による事故を防ぎます。

とくに重要なのは、SRI がバージョン固定を前提とする点です。CDN が同じ URL で内容を更新する運用（latest を指す等）では、更新のたびに integrity を書き換えねばならず、書き換え漏れがあれば正規の更新版まで弾かれます。だから SRI はバージョン番号を URL に含めた不変（immutable）なファイルに対してかけるのが原則です。

また SRI は注入されたインラインスクリプトを防げません。これは Content Security Policyの内部動作と回避耐性 の領域です。実務では SRI（外部リソースの完全性）と CSP（実行可能ソースの制限）を組み合わせ、SRI 自体を強制する Integrity-Policy ヘッダや CSP の script-src 厳格化と重ねることで、外部依存と注入の両面を抑えます。

まとめ