外部CSSのSRIとは？スタイルシートへのintegrity属性の付け方・自己ホスト・診断基準

外部CSSのSRIとは

外部CSSのSRIとは、外部のCDNやサーバーから読み込むスタイルシートの link rel="stylesheet" 要素に、integrity 属性で期待するハッシュ値を書いておき、ブラウザが取得したCSSのハッシュが一致しない場合にそのスタイルシートを適用させない仕組み（Subresource Integrity）です。

外部CSSにも、JavaScriptと同様にSRIを設定できます。CSSはJavaScriptのように任意の処理を実行できませんが、改ざんされると画面表示の偽装や、属性セレクターと背景画像を組み合わせた情報の外部送信などに悪用される可能性があります。セキュリティAIチェッカーのこの項目は、トップページで読み込まれている外部CSSに有効なSRIが付いているかを確認します。重大度はJavaScriptより低いlow、重みは1です。

<link rel="stylesheet"
      href="https://cdn.example.net/icons/2.1.0/icons.min.css"
      integrity="sha384-（ファイルのSHA-384ハッシュをBase64で表した値）"
      crossorigin="anonymous">

外部JavaScriptのSRIは「外部JavaScriptのSRI」で別に確認します。

外部CSSが改ざんされると何が起こるのか

• 表示の偽装：注意書きや問い合わせ先を display:none で隠し、::before/::after の content で偽の電話番号や文言を表示させる。
• 情報の外部送信：属性セレクターと background-image: url(...) を組み合わせると、入力欄の value 属性など、HTML属性に含まれる値を1文字ずつ外部へ送信させる手法が知られています（CSSインジェクション）。
• クリックの誘導：透明な要素や配置の変更で、利用者に意図しないリンクやボタンを押させる。
• 外部リソースの読み込み：@import や url() により、改ざん者のサーバーへアクセスさせ、閲覧の事実を記録する。

JavaScriptに比べれば影響は限定的ですが、ASVS 5.0.0 V3.6.1はJavaScriptだけでなくCSSやWebフォントも明示的に対象にしています。

SRIの仕様上の要点（CSSの場合）

• 対応するハッシュ関数はSHA-256、SHA-384、SHA-512です（W3C SRI）。
• integrity の値に有効なハッシュ指定が1つもない場合（空の値、未対応のアルゴリズムのみ）、ブラウザは検証を行いません。仕様は、未対応のハッシュ関数による指定は「integrityの値がなかったのと同じ」に扱うとしています。
• 別オリジンの資産にSRIを使うにはCORSが必要です。crossorigin="anonymous" を付け、配信元が Access-Control-Allow-Origin を返す必要があります。

SRIが向かないCSS（Webフォントサービスなど）

Webフォントサービスが返すCSSのように、ブラウザの種類や要求内容によって中身が変わるものには、SRIを付けられません。その場合は、フォントとCSSを自己ホストするか、CSPの style-src と font-src で配信元を限定します。

外部CSSのSRIの診断基準（セキュリティAIチェッカー）

取得対象

• 入力URLのリダイレクト後の最終URLのHTML本文（最大2MB）を対象にします。
• rel="stylesheet"（引用符付きで値が stylesheet のもの）を持つ link 要素のうち、href をページURL基準で解決したオリジンがページのオリジンと異なるものを評価します。
• @import で読み込まれるCSSや、JavaScriptが動的に追加するCSSは対象外です。

「有効なSRI」の条件

integrity 属性の値（空白区切りで複数指定可）に、sha256-、sha384-、sha512- のいずれかで始まりBase64文字が続くハッシュ指定が1つ以上含まれることが条件です。integrity="md5-... sha384-..." のように2番目以降にある指定も有効と認めます。空の値や未対応アルゴリズムのみの値は、ブラウザが検証しないため「SRIなし」と数えます。ハッシュ値と実ファイルの一致は、追加取得を行わないため確認しません。

判定条件

• 根拠欄には「SRIなし: 未設定件数/外部CSS件数」を表示します。
• 動的に生成されるCSS（Webフォントサービス等）にはSRIを付けられない正当な理由があり、ASVS上もL3要件であるため、×（fail）ではなく△としています。

自治体サイトでの判定例

検出の限界

• rel="stylesheet" の値が完全一致する（大文字小文字は区別しない）link 要素のみを対象とするため、rel="alternate stylesheet" や引用符なしの rel=stylesheet は数えません。href の値を引用符で囲んでいないものも数えません。
• CSS内の @import で読み込む外部CSS、JavaScriptが追加する link 要素、style 要素内の外部参照は対象外です。
• integrity の形式が正しくても、実ファイルのハッシュと一致しなければブラウザはスタイルを適用しません。診断が○でも、表示崩れがないかブラウザで確認してください。

外部CSSの種類別の対応目安

外部CSSが少数で、すべて版固定のライブラリであれば、自己ホストに切り替えるのが最も簡単で確実です。自己ホストにすればこの項目は対象外となり、外部依存の管理対象も減ります。

外部CSSにSRIがないとどんなリスクがあるか

• 偽情報の表示：改ざんされたCSSで、避難所や窓口の電話番号、受付時間などを偽の内容に見せかけることができます。自治体サイトは住民が信頼して行動の根拠にするため、影響は小さくありません。
• 入力内容の一部漏えい：CSSインジェクションの手法により、HTML属性に出力された値（検索語や入力欄の値など）が外部へ送信される可能性があります。
• サプライチェーン経由の改ざん：外部CDNのアカウント侵害やドメイン譲渡が起きた場合、自治体側は何も変更していなくても表示が改ざんされます。2024年のpolyfill.ioの事例は、配信元ドメインの所有者変更で配信内容が改変されうることを示しました（この事例はJavaScriptです）。

外部CSSにSRIを設定する方法・自己ホストへの移行（Apache・nginx・IIS・Next.js）

1. SRI値の作成と記述

curl -s https://cdn.example.net/icons/2.1.0/icons.min.css \
  | openssl dgst -sha384 -binary | openssl base64 -A

<link rel="stylesheet"
      href="https://cdn.example.net/icons/2.1.0/icons.min.css"
      integrity="sha384-（上で計算した値）"
      crossorigin="anonymous">

CSSが相対パスでフォント等を参照している場合、SRIはCSSファイル本体だけを検証し、参照先のフォントは検証しません。フォントの改ざん対策が必要なら、フォントも自己ホストします。

2. 自己ホストへの移行（推奨）

外部CSSの多くは、ファイルを自サイトに置くことで外部依存そのものをなくせます。

<!-- 変更前 -->
<link rel="stylesheet" href="https://cdn.example.net/icons/2.1.0/icons.min.css">
<!-- 変更後 -->
<link rel="stylesheet" href="/assets/vendor/icons-2.1.0/icons.min.css">

Webフォントは、利用規約で自己ホストが認められているフォントを選び、@font-face で自サイトから配信します。

@font-face {
  font-family: "SiteSans";
  src: url("/assets/fonts/sitesans-regular.woff2") format("woff2");
  font-display: swap;
}

3. CSPで配信元を限定

Apache（.htaccess）

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "style-src 'self' https://cdn.example.net; font-src 'self' https://cdn.example.net"
</IfModule>

nginx

add_header Content-Security-Policy-Report-Only "style-src 'self' https://cdn.example.net; font-src 'self' https://cdn.example.net" always;

IIS（web.config）

<add name="Content-Security-Policy-Report-Only" value="style-src 'self' https://cdn.example.net; font-src 'self' https://cdn.example.net" />

Next.js

next.config.js の headers() で同じ値を返します。

4. 段階的な導入手順

1. 外部CSSを一覧化し、版固定のライブラリと動的に生成されるCSSに分ける
2. 版固定のものは、まず自己ホストへの移行を検討する（ライセンスと利用規約を確認）
3. 外部配信を続けるものは、検証環境で integrity と crossorigin を付けて、主要ページの表示をPCとスマートフォンで確認する
4. 本番に反映し、コンソールのエラーと表示崩れがないことを確認する
5. ライブラリ更新時にSRI値を再計算する手順を、更新手順書に追加する

5. 確認方法

curl -s https://www.city.example.lg.jp/ | grep -o -i -E '<link[^>]*stylesheet[^>]*>'

ブラウザの開発者ツールのコンソールで、integrityの不一致やCORSのエラーによりスタイルシートがブロックされていないかを確認します。ブロックされると、その部分のデザインが崩れます。対応後はセキュリティAIチェッカーで再診断し、根拠欄の「SRIなし」の件数を確認してください。

サイトを壊さないための注意点

• style-src を強制すると、インラインの style 属性や style 要素が多いCMSでは表示が大きく崩れます。CSPは必ずReport-Onlyから始め、インラインスタイルの扱い（'unsafe-inline' を残すか、nonce/hashに移行するか）を決めてから強制してください。インラインの許可は「CSPでunsafe-inlineを許可していない」で確認します。
• CDN側でファイルが更新される版指定なしのURLにSRIを付けると、更新時に突然スタイルが適用されなくなります。版を固定してから付与してください。
• crossorigin 属性を付けずにintegrityだけを付けると、別オリジンのCSSは読み込みに失敗します。

よくある質問（FAQ）

参考資料

• W3C Subresource Integrity
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.6.1）
• OWASP Third Party JavaScript Management Cheat Sheet
• Sansec「Polyfill supply chain attack」

「外部CSSのSRI」と関連する診断項目

• 外部JavaScriptのSRImedium
• CSPでunsafe-inlineを許可していないhigh
• 外部資産のバージョン固定medium
• Mixed Contentがないhigh
• WebSocketをWSSで暗号化high
• 廃止されたクライアント技術を使用していないhigh
• postMessageの送受信元を限定high
• 外部JavaScript依存数medium