SRIが検証する内容と配信時の確認条件
サブリソース完全性は期待した内容と応答を照合します。ハッシュの選択、CORSの許可、ファイルとメタデータの更新を併せて確認します。
発行・訂正窓口:infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
SRIは取得したリソースと期待する内容の一致を検証し、CORSは別オリジンの応答を検証できるかを決めます。
概念図であり、実際のハッシュや測定結果は示していません。
期待する内容から検証が始まる
SRIはスクリプトやスタイルシートの期待するダイジェストを指定し、取得した内容と比較する仕組みです。適用される照合に失敗すると、そのリソースは拒否されます。ただし不一致は悪意ある改ざんの診断ではありません。通常の更新でも古い期待値と一致しなくなります。判定するのは宣言した内容との一致であり、変更者の意図やコードの安全性ではありません。
期待値を載せた文書も信頼の境界に含まれます。攻撃者がファイルと文書内のハッシュを共に変更できれば、元の作成者の期待は保たれません。一致するコードにも望ましくない動作はあり得ます。これは内容の同一性を調べる機能から導かれる限界で、実際の事件を示すものではありません。 期待内容の境界
アルゴリズムと選択集合を読む
integrityの表現はアルゴリズムとBase64ダイジェストを指定します。認識する最も強いアルゴリズムの集合を選び、その値のどれかとの一致を認めます。弱い一致は強い集合の不一致を補えません。SHA-384は2016年勧告の基準として論じられ、唯一の許可算法ではありません。 選択規則
複数の値を配信者の承認一覧ではなく期待値の集合として読みます。仮の配信では二つの値が許可された二つのファイルに対応し得ます。コピーする前に各値がどのファイルを表し、なぜ両方を許容するのかを尋ねられます。関係が不明なら配信の説明も難しくなります。この例は文書化の練習で、実用のダイジェストやブラウザー試験結果ではありません。
オリジンの許可は別の条件
同一オリジンの応答は検証対象になり得ますが、別オリジンではCORSで読める応答が必要です。integrityを追加してもアクセス許可は得られません。要素のcrossoriginとサーバーの許可応答を併せて確認します。通常のクラシックスクリプトにハッシュだけを付けても別オリジンの条件を満たせず、モジュールにも独自のCORS要件があります。 script要素
MDNはanonymousとuse-credentialsを区別します。前者は別オリジンに資格情報を送らず、後者は送信を要求します。資格情報付きCORSには具体的な許可オリジンと資格情報の許可が必要で、許可オリジンのワイルドカードでは代用できません。 資格情報付きCORSanonymousは一般的な設定ですが唯一の選択とは限りません。実際の要求と応答を調べる必要があります。 資格情報モード
ファイルと期待値を一緒に更新する
仮の配信でライブラリーだけを更新し、ページに旧ダイジェストを残すと、新ファイルが拒否され得ます。逆にメタデータを先に更新し、キャッシュが旧版を返しても不一致になります。どちらも通常の配信変更で起こり得るため、それだけで攻撃とは判断できません。
照合対象は仕様が定める表現データで、コンテンツ符号化を処理したものです。特定ブラウザーのメモリ構造や圧縮された通信バイトをそのまま計算するという保証ではありません。最終配信物を識別し、文書の期待値と同期させます。頻繁な変更には更新の調整が必要ですが、完全性検証が構造上不可能になるわけではありません。 表現と配信
専門的視点から運用の限界を見る
MDNの専門文書は実務上の確認項目を示します。要素とURL、ダイジェスト、要求元と資格情報モード、CORSの応答を順に確認できます。正しい内容と意図的な不一致を別々に試せば、アクセス許可の問題と内容の問題を区別しやすくなります。拒否されたスクリプトが依存する機能に影響しても、仕様が定めるのは該当リソースの拒否であり、全アプリの停止ではありません。
失敗時の動作や代替経路も検討します。手動の計算が本質的に無効、特定のビルドツールが必須という根拠はありません。SRIは信頼できる期待値と検証可能な応答を前提とする限定的な確認です。コードレビューなどは別の問題を扱います。安定した規則は2016年勧告に基づき、読んだ最新W3Cページは2026年の作業草案です。新機能が広く実装済みという証拠ではありません。 草案の状態 MDNの適用説明