共有HTMLが読み込む外部CDNが改ざんされたら｜サプライチェーン視点の確認

外部CDN依存がなぜリスクになるのか

多くのHTMLは、jsDelivrやcdnjsといった公開CDNからライブラリを読み込みます。読み込み先のファイルはあなたの管理下にありません。もし配信元やそこに置かれたファイルが書き換えられれば、あなたのページはそのまま改ざんされたコードを実行してしまいます。

怖いのは、自分のHTMLを一切触っていなくても被害が起きる点です。ページの見た目や挙動は普段どおりに見えるため、利用者も作者も改ざんに気づきにくく、認証で閲覧者を絞っていても内部で動くコードまでは守れません。

改ざんされたとき何が起きるか

読み込んだスクリプトはページと同じ権限で動くため、フォーム入力の盗み取り、表示内容のすり替え、別サイトへの誘導など、できることは多岐にわたります。閲覧者の環境で実行される以上、影響は配布した人数だけ広がります。

CSSの改ざんでも、要素を隠したり偽の表示を重ねたりといった視覚的な攻撃が可能です。スクリプトに比べて軽視されがちですが、フィッシングの土台になりうるため油断はできません。

よくあるNG例と安全な直し方

共有HTMLが読み込む外部CDNが改ざんされたら｜サプライチェーン視点の確認では、「検索に出さない」と「見られないようにする」を混同しないことが重要です。noindexやrobots.txtは検索エンジンへの指示であり、アクセス制限そのものではありません。

安全に共有するには、誰に見られると困るかを先に決め、URL共有だけで足りるのか、認証や期限が必要なのかを選びます。共有相手と機密度が決まったら、URLのみ・パスワード・メール認証・会社ドメイン認証のどれで渡すかを選びます。

• NG: 機密情報入りHTMLを認証なしURLで共有し、noindexだけで安心する
• OK: パスワード・メール認証・会社ドメイン認証で閲覧者を絞る
• NG: テスト用APIキーや社内URLをHTML内に残したまま渡す
• OK: 公開前に外部送信先、秘密情報、フォーム送信先を確認する

バージョン固定と整合性検証で守る

対策の基本は、読み込むファイルを特定の状態に固定することです。latestのような可変の指定ではなく、明確なバージョン番号を指す形にすれば、知らぬ間に中身が差し替わる範囲を狭められます。

さらに強い対策が整合性検証です。読み込むファイルのハッシュ値を事前に控えておき、ブラウザが取得したファイルのハッシュと一致しなければ実行しない仕組みを使えば、配信元が書き換えられても改ざん版の実行を防げます。最も確実なのは、外部依存をやめて必要なファイルを自分の配布物に同梱してしまう方法です。

外部依存を点検する手順

共有する前に、自分のHTMLが何を外部から読み込んでいるかを棚卸ししておきましょう。次の順で確認すると漏れが減ります。

点検は一度きりではなく、配布物を更新するたびに繰り返すのが理想です。新しいライブラリを足したときに、知らないうちに外部依存が増えていることはよくあります。チェックリストとして手元に残しておくと習慣化しやすくなります。

1. HTML内のscriptとlinkタグの読み込み先URLをすべて洗い出す
2. 外部ドメインを指すものに印を付ける
3. latestなど可変の指定を具体的なバージョン番号に置き換える
4. 可能なら各ファイルにハッシュによる整合性検証を付与する
5. 機密度が高い配布物は外部依存をやめて同梱する
6. 残した外部依存は配信元と提供元の信頼性を確認する

ZIPで配るときの注意

CSSやJS、画像をまとめたZIPを共有する場合でも、その中のHTMLが外部CDNを参照していれば同じリスクが残ります。同梱したつもりでも、一部だけ外部読み込みのままになっていないかを確認してください。

オフラインでも完結する形に寄せておくと、配信元の障害や改ざんに左右されず、表示の再現性も高まります。レビューや一時共有の用途では特に有効です。

ギガサイト便での共有とサプライチェーン

ギガサイト便はHTMLやZIPをそのままエッジ配信し、共有URLとして公開します。配信は速く安定しますが、HTMLが外部CDNを参照していれば、その依存先のリスクは配信方法に関わらず残ります。安全性は同梱や整合性検証など、HTML側の作りで担保する必要があります。

認証や公開期限で閲覧者と公開範囲を絞りつつ、配布物の外部依存を点検しておくと、サプライチェーン由来のリスクを現実的な範囲まで下げられます。