東芝や無印良品をはじめ複数の企業サイトで、正規ページ上に「不審なログイン画面」が表示される事案が相次ぎ、各社が注意喚起を行った。利用者視点ではフィッシングサイトに誘導されたように見えるが、今回のポイントは「正規ドメインのページ表示中に偽の入力画面が出る」点にある。背景として指摘されているのが、外部配信のJavaScriptサービスである「polyfill.io」経由の改ざん・注入リスクだ。本稿では、なぜこの種の事案が起きるのか、企業と利用者が取るべき対策は何かを、Webセキュリティとサプライチェーンの観点から整理する。
正規サイトに偽ログインが出る仕組み
従来のフィッシングは「偽サイトへ誘導して入力させる」手口が中心だった。一方、サードパーティのスクリプトが改ざんされると、攻撃者は正規サイトの表示・挙動をページ内で直接書き換えられる。具体的には、外部CDNや解析タグ、チャットウィジェット、広告タグなどから読み込むJavaScriptが悪性化し、ページ上にログインフォーム風のモーダルやポップアップを重ねて表示し、入力内容を窃取して外部に送信する、といった攻撃が可能になる。
利用者から見ると「URLは正しい」「鍵マークも出ている」のにログインを促され、つい入力してしまう。これがサプライチェーン型のWeb改ざんが厄介な理由であり、ブランド毀損だけでなく、アカウント乗っ取り、決済情報詐取、二次被害（他サービスの使い回し被害）へ連鎖し得る。
polyfill.ioとは何か、なぜ影響が広がるのか
polyfill.ioは、古いブラウザで不足する機能を補う「polyfill」スクリプトを配信する用途で広く利用されてきた。開発者は、自社サーバで配布する代わりに外部サービスのスクリプトを読み込むだけで互換性対応を実現できるため、導入が容易だった。だが、この「容易さ」は同時にリスクでもある。もし配信元が乗っ取られたり、配信内容が意図せず変更された場合、当該スクリプトを参照する多数のサイトが一斉に影響を受ける。
さらに厄介なのは、サイト運用の過程でスクリプト参照が長期間放置されやすい点だ。フロントエンドの移行やCMS更新を繰り返すうちに、過去に貼ったタグが残り続け、実際には不要になっていても読み込まれていることがある。結果として「誰も意識していない外部依存」が攻撃面を広げる。
企業側の優先対応：まず“止血”し、次に再発防止へ
外部スクリプトの棚卸しと遮断
最優先は、該当ドメイン・パスからの読み込みを停止し、影響範囲（どのページで読み込んでいるか）を特定することだ。CMSの共通ヘッダ、タグマネージャ、広告配信設定、A/Bテストツールなど、複数箇所に重複して埋め込まれているケースもあるため、HTMLテンプレートだけでなく運用系ツールも含めて確認する必要がある。
Subresource Integrity（SRI）とCSPの導入
再発防止として有効なのがSRI（読み込むスクリプトのハッシュを固定し、内容が変わったら読み込み失敗にする）と、CSP（Content Security Policy：許可したスクリプト以外の実行や送信先を制限する）だ。特にCSPは、悪性化したスクリプトが外部へデータ送信する経路を抑止できる場合がある。ただし既存サイトにいきなり厳格なCSPを適用すると表示崩れや機能停止を招くため、レポートモードでの段階導入が現実的だ。
セルフホストと依存削減
互換性対応が今も必要なら、外部サービス依存をやめて自社でスクリプトをホスティングし、更新手順と変更管理（レビュー、署名、CI/CDでの検証）を整えるべきだ。また、現在の主要ブラウザ環境では、多くのpolyfill自体が不要になっていることがある。アクセス解析で古いブラウザ比率を確認し、不要な互換コードを削除するだけでもリスクと性能負荷を同時に下げられる。
検知とログ：改ざん“後”の気付きも設計する
Web改ざんは「侵入されない」だけでなく「早く気付く」ことが重要だ。合成監視（特定ページを定期的に巡回しDOM変化や不審なフォーム出現を検知）、CSPレポート収集、WAFログ、ブラウザコンソールエラーの監視、タグマネージャの変更監査などを組み合わせ、兆候を早期に捉える体制が求められる。
利用者側ができる自衛策
企業が対策を進めても、発生直後は利用者が被害を避ける行動が重要になる。正規サイト上で突然ログインを求められた場合は、一度閉じて公式アプリやブックマークから入り直す、ブラウザの拡張機能で広告・トラッカーを制限する、OSやブラウザを最新化する、といった基本策が有効だ。万一入力してしまった場合は、当該サービスのパスワード変更、同一パスワードを使い回している他サービスの変更、可能なら多要素認証の有効化を急ぎたい。
今回の示唆：Webは“外部依存の集合体”になっている
近年の企業サイトは、決済、チャット、解析、広告、A/Bテスト、レコメンドなど、多数の外部スクリプトで構成される。便利さの代償として、1つの外部依存が侵害されれば、正規サイトが攻撃の踏み台になり得る。今回の「不審なログイン画面」事案は、サプライチェーン攻撃がサーバ侵入だけでなく、フロントエンド配信経路でも現実化していることを改めて示した。
企業は、外部スクリプトを“貼ったら終わり”にせず、棚卸し、最小化、検証、監視まで含めた運用設計に切り替える必要がある。利用者の信頼は、見た目の安全表示だけでは守れない。正規サイトを安全に保つための、地道だが確実な依存管理こそが、今後のWebセキュリティの中核になる。