悪意あるブラウザ拡張機能とは？Chrome拡張の危険性と企業対策を徹底解説

なぜブラウザ拡張機能が危険になるのか

拡張機能は『追加機能』ではなく、閲覧中の業務文脈へ入り込むコードです

ブラウザ拡張機能は、見た目には小さな補助機能に見えます。しかし実態は、閲覧中のページに重なり、通信や入力を補助し、場合によってはクッキーやコンテンツスクリプトを通じて業務文脈へ深く入り込むコードです。だから危険性を判断するときは、「ストアにあるから安全」ではなく、どの権限と更新経路を持ち、何のページへ触れられるのかを見る必要があります。

既存の 悪意ある npm / PyPI パッケージ がパッケージ配布基盤の供給網を主役にしているのに対して、本記事の主役はブラウザ拡張機能の配布基盤です。パッケージと同じく配布と更新の信頼が論点になりますが、拡張機能はさらに利用者のブラウザ内へ入るため、閲覧中のセッションや業務ページと距離が近いという違いがあります。

そのため、拡張機能はマルウェア単体というより、認証済みのブラウザ、社内 SaaS、管理画面、開発ツールへ横から届く接点として考えた方が実務に合います。たとえば、特定ホストへのアクセス、クッキー参照、スクリプト注入、通信リクエストの書き換え、クリップボードやダウンロードの操作ができると、利用者が見ている業務画面の文脈そのものが攻撃者の材料になります。

危険なのは『露骨に怪しい拡張』だけではありません

多くの現場で誤解されやすいのは、悪意あるブラウザ拡張機能というと、最初から攻撃目的で作られた拡張だけを想像してしまうことです。実際には、最初は便利な機能として配布され、後から更新で権限が増えるもの、開発者アカウントが乗っ取られて差し替えられるもの、買収や管理者交代で方針が変わるものもあります。つまり危険なのは、今の見た目が怪しいかどうかではなく、将来の更新を含めて信用を保てるかです。

Chrome Web Store の運用ポリシーは、人を欺く動作や隠れた機能を禁じていますが、審査があることと運用上のリスクがゼロであることは別です。Chrome の権限警告でも、利用者に対象サイトへのアクセス権や強い権限を警告として見せる仕組みがあります。これは逆に言えば、権限が強い拡張はブラウザ側も危険度が高いと認識しているということです。

さらに、利用者は一度便利さを体験すると、その拡張が何に触れられるかを見直さなくなりがちです。権限警告は初回導入時や権限追加時にしか真剣に見られないことが多く、更新後の挙動まで継続的に追う運用は企業側で補わなければなりません。したがってブラウザ拡張機能の安全管理は、インストール審査より継続管理が本体です。

企業環境では、個人のブラウザ便利機能がそのまま業務接点になります

個人用途では無害に見える拡張でも、企業環境では事情が変わります。営業、サポート、開発、採用、バックオフィスなど、それぞれがブラウザ上で顧客データ、請求情報、コード管理、管理画面、社内ナレッジベースに触れるからです。そのブラウザに強い権限を持つ拡張が入ると、問題は個人の閲覧習慣ではなく、業務接点の安全性になります。

既存の インフォスティーラーとは？ や セッショントークン窃取とは？ で扱ったように、認証済みセッションやブラウザ内の機微情報はそれだけで高い価値を持ちます。ブラウザ拡張機能は、その前段で何に触れられるかを決めるため、トークン窃取と別記事でありながら密接につながる管理対象です。

どの権限と更新経路が危ないのか

対象サイトへのアクセス権、クッキー、スクリプト実行に近い権限は特に注意が必要です

Chrome の権限警告が重いのは、ブラウザ拡張機能が閲覧中のサイトやローカル資源へ近づけるからです。とくに対象サイトへのアクセス権、クッキー、タブ、スクリプト実行、通信リクエスト変更、クリップボード、ダウンロードなどは、単独でも危険ではありませんが、組み合わさると業務サイトの内容把握やセッションの悪用につながりやすくなります。つまり見るべきなのは「危険な権限一覧」ではなく、その権限がどの業務ページへ届くかです。

たとえば広い対象ホスト指定を持つ拡張は、顧客管理、社内管理画面、SaaS 管理画面など、利用者が開く多くのページと接点を持てます。もしクッキーや保存領域へ届けば、認証済み状態の周辺情報に触れる可能性も高まります。ここで重要なのは、権限名を単語として眺めるより、ブラウザ内のどの資産へ手が届くかで評価することです。

さらにコンテンツスクリプトは、表示されている DOM や入力内容に近いため、業務アプリ上で扱う情報と接触しやすくなります。利用者から見ると便利機能の一部でも、組織から見ると「どのページで何に触れられるか」を明文化しておく必要があります。ここを曖昧にしたまま導入すると、後から権限追加があっても危険度を評価できません。

更新経路と提供元の真正性は、初回導入と同じくらい重要です

拡張機能は一度許可されると、以後の更新も信頼連鎖に入ります。だからブラウザ拡張機能の安全管理では、初回審査以上に更新経路が重要です。Chrome Enterprise の ExtensionSettings ポリシーでも、インストール方法や更新 URL の上書きを管理できるのは、この更新経路を制御しなければリスクを抑えにくいからです。つまり企業に必要なのは、何を入れるかだけでなく、どこから更新されるかを固定することです。

開発者アカウントの乗っ取りや所有者変更が起きると、利用者は同じ拡張を使っているつもりでも、実際には別の管理主体からコードを受け取る状態になります。これはマルウェア配布と完全に同じではないものの、企業にとっては供給網リスクです。更新通知や権限変更通知を追わないまま使い続けると、危険な変更を便利機能の更新として受け入れてしまいます。

ここで役立つのが、提供元の見直しを月次タスクへ入れることです。拡張機能名、ID、提供元、権限、対象ホスト、導入理由、代替手段、最終確認日を台帳化すると、突然の権限増加やストア掲載情報の変化に気づきやすくなります。ブラウザ拡張機能の管理は、インストール申請よりも変更監視が本体だと考えた方が実務に合います。

企業でどう管理すべきか

許可リストと禁止権限を組み合わせると現実的です

ブラウザ拡張機能の管理を利用者教育だけに頼ると、便利な機能ほど例外が増え、最終的に何が許可済みか分からなくなります。そこで現実的なのが、許可リストを中心にしつつ、必要に応じて禁止権限や実行時に遮断する対象ホストを組み合わせる方法です。Chrome Enterprise の管理機能でも、インストール可否と権限制御を同時に設計することが前提になっています。

許可リストだけでは、許可済み拡張の権限が広すぎる場合を見落とします。逆に禁止権限だけでは、何を使ってよいのかが曖昧になります。そのため実務では、「何を使ってよいか」「その拡張がどこへ触れてよいか」を分けて管理する方が、利用者にも管理側にも分かりやすくなります。

とくに業務ブラウザでは、顧客データや管理画面に触れる部署だけ別ポリシーにする、経理システムや管理画面に対して実行時に遮断する対象ホストを強める、といった役割別制御が有効です。拡張機能管理は、全社一律に一つの一覧を配るだけではなく、部門と接触データに応じて分ける方が再現性のある運用になります。

台帳と月次レビューがないと、権限増加を追えません

拡張機能の管理で最も起きやすい失敗は、一度承認したあと誰も見直さないことです。ブラウザ拡張は数が増えやすく、同じ機能の代替も多いため、使われなくなったものや、導入理由が不明なものが残りがちです。ここで必要なのが、拡張機能 ID、提供元、権限、対象ホスト、承認理由、見直し日を残した台帳です。台帳があると、権限の広い拡張だけを後から絞り込みやすくなるためです。

また、月次レビューでは「インストール数」よりも「権限追加」「提供元変更」「未承認拡張」「削除候補」を見る方が有効です。数字だけ追うと、便利機能の普及は見えても、危険度の変化は見えません。ブラウザ拡張機能は追加された瞬間より、更新で挙動が変わったときに事故へ近づきやすいので、変更点を定期的に見る必要があります。

さらに、管理対象ブラウザと未管理ブラウザを混在させないことも重要です。私用ブラウザで業務 SaaS へ入る運用や、個人のプロファイルに拡張機能を自由導入できる状態では、組織の許可リストが効きません。拡張機能管理を実効的にするには、ブラウザ自体の管理境界も含めて考えなければなりません。

ブラウザ拡張機能をトークン窃取やフィッシングの前段として監視します

ブラウザ拡張機能の危険性は、単独で完結するとは限りません。既存の フィッシング対策とは？ や セッショントークン窃取とは？ で扱ったように、ブラウザに近い場所で権限を持つものは、認証済みの文脈とつながりやすくなります。だから拡張機能管理はブラウザ便利機能の棚卸しではなく、認証後の接点管理として見た方が、他の施策と統合しやすくなります。

実務では、拡張機能管理を認証基盤、トークン、SaaS、ブラウザ管理ポリシーと別々の会議で扱うより、同じブラウザ衛生の定例見直しとしてまとめた方が運用しやすくなります。そうすると、「この拡張はどの SaaS と接触するか」「この権限はトークン窃取の前提にならないか」をまとめて見られるようになります。結局のところ、企業でのブラウザ拡張機能管理は、ブラウザを業務端末の重要な接点として扱うかどうかにかかっています。

既存のフィッシング対策やトークン窃取対策とどうつながるか

拡張機能は『別テーマ』ではなく、既存のブラウザリスクを増幅します

悪意あるブラウザ拡張機能は、既存のフィッシングやトークン窃取とは別物に見えますが、実務上は分離できません。フィッシングによって利用者が誘導されるブラウザ、セッショントークンを保持しているブラウザ、業務 SaaS へ入っているブラウザに拡張機能が入り込むからです。したがって拡張機能の話は、認証やマルウェアとは別の小話ではなく、ブラウザ上で起きる複合的なリスクの一部として整理した方が意味があります。

たとえば クレデンシャルスタッフィングとは？ や パスワードスプレーとは？ で認証が突破される経路を学んでも、ブラウザ側の拡張管理が弱ければ、その後のセッションや業務操作の安全性は別問題として残ります。逆に拡張機能管理だけ強くしても、認証自体が弱ければ被害は起きます。つまりブラウザ拡張機能の安全管理は、ブラウザ内の権限管理を他の認証対策へ接続する役割があります。

さらに、利用者はブラウザ拡張機能を「入れて便利になるもの」と認識しやすく、危険性が説明しにくいという難しさがあります。ここでは技術詳細を並べるより、どの業務画面へ触れるか、クッキーや入力内容にどこまで近いか、更新で何が変わりうるかを説明した方が伝わります。企業の教育でも、権限名より業務影響で説明する方が定着しやすいです。

許可と禁止をどう決めるか

業務上の必須性と代替手段を最初に確認します

拡張機能の審査で最初に確認したいのは、便利かどうかではなく、その拡張機能が本当に業務上必要かという点です。画面の見やすさや入力補助のような目的なら、ブラウザ標準機能や SaaS 側の設定で代替できることもあります。代替できるのに高い権限を持つ拡張機能を残すと、便利さのために不要な接点を増やすことになります。

逆に、翻訳、入力支援、開発補助、検証支援のように業務上どうしても必要な場合は、利用部門、対象サービス、対象ブラウザ、利用期限を明文化しておくべきです。ここが曖昧だと、一度許可した拡張機能が半永久的に残り続けるうえ、誰が見直すのかも不明になります。許可の基準は、機能の派手さではなく、用途と期限まで説明できるかで決めた方が安全です。

権限の名前ではなく、触れる画面で優先順位を付けます

実務では、権限一覧をそのまま見ても優先順位を付けにくいことがあります。そこで有効なのが、拡張機能がどの業務画面やどの公開サービスに触れうるかで並べ直す方法です。財務、人事、顧客情報、開発基盤、管理画面へ届く拡張機能は、同じ権限構成でも影響が重くなります。

たとえば、閲覧履歴やページ内容に触れられる拡張機能でも、一般的な情報収集サイトだけに使うのか、顧客管理 SaaS や管理画面でも使うのかで意味が変わります。したがって、許可審査では権限名だけでなく、利用者が日常的に開く重要画面との組み合わせを見る必要があります。ここまで見えると、拡張機能管理を認証対策、SaaS 管理、公開面管理とつなげやすくなります。

更新後の再承認と削除の条件まで決めておきます

許可判断で見落としやすいのが、インストール時の確認だけで終わることです。しかし、危険性はその後の更新、提供者変更、権限追加、サポート終了で変わります。そこで必要になるのが、更新後に再承認が必要になる条件と、使われていない拡張機能を削除する条件を先に決めておくことです。

たとえば、権限が増えたとき、提供者が変わったとき、対象ホストが広がったとき、一定期間使われていないときは再審査に戻す、といったルールが考えられます。ここまで定義できると、許可リストは単なる一覧表ではなく、減らす運用と見直す運用を含んだ統制になります。拡張機能管理を長く回すには、導入可否だけでなく、外す条件と見直す条件まで決めることが重要です。

悪意あるブラウザ拡張機能の見直しを ASM診断 PRO で始めるなら

ASM診断 PRO はブラウザ拡張機能を検査する専用製品ではありませんし、Chrome Enterprise のポリシー管理そのものを置き換えるものでもありません。それでも導入動線として意味があるのは、ブラウザ拡張機能の危険性を考えるとき、実際に利用者が触れているログイン画面、管理画面、SaaS の接点、公開 API、古い検証環境を外から見える形で整理できるからです。拡張機能の権限は抽象的でも、どの公開面へ触れうるか は具体的に棚卸しできます。

とくにブラウザ拡張機能の危険性は、権限一覧だけ見ても優先順位が付けにくいです。ところが、今どの管理画面、顧客向け SaaS、検証環境、サポート窓口が外に出ているかが分かると、「この拡張が触れたらまずい面」はかなり絞れます。ASM診断 PRO を使って公開面を把握しておくと、拡張機能の許可リスト見直しをブラウザ管理ポリシーだけでなく、実際の公開接点の重要度に基づいて進めやすくなります。

既存の 外部接続点は見えているか？、セッショントークン窃取とは？、公開リポジトリの情報漏えいとは？ と組み合わせると、ブラウザ拡張機能、トークン、公開面、機密情報露出を分断せずに見直せます。ブラウザ拡張機能の安全管理を「便利機能の注意点」で終わらせず、業務ブラウザが触れている外部公開面の棚卸しまでつなげたいなら、まずは いま外から見えている接点の整理 から始めてください。

よくある質問（FAQ）

Chrome Web Store にある拡張機能なら安全ですか

いいえ。審査は重要ですが、権限の広さ、提供元の変化、更新後の挙動、業務環境との接触範囲まで自動で保証してくれるわけではありません。

危ない権限は一つに決められますか

一つには決めにくいです。重要なのは権限名だけでなく、どのホストに触れ、クッキーや入力内容に近いか、更新後も同じ前提で使えるかを合わせて見ることです。

利用者教育だけで対策できますか

不十分です。許可リスト、禁止権限、実行時に遮断する対象ホスト、管理対象ブラウザ、台帳、月次レビューを組み合わせて、利用者の判断だけに依存しない運用が必要です。

ブラウザ拡張機能はマルウェアと同じですか

常に同じではありません。ただし、業務ブラウザの文脈へ深く入り込むコードである以上、マルウェアと同様に権限、更新、信頼経路を確認する必要があります。

最初に何から見直すべきですか

まずは業務端末で使われている拡張機能の一覧、提供元、権限、対象ホストを棚卸しし、許可リストと月次レビューの基盤を作るところから始めてください。

まとめ

悪意あるブラウザ拡張機能の問題は、怪しい追加機能を見つけることだけではありません。ブラウザ拡張機能は、閲覧中の業務ページ、クッキー、入力内容、通信先、更新経路に近い位置へ入るため、組織にとってはブラウザそのものの管理課題です。だから判断の中心は「便利そうかどうか」ではなく、どの権限を持ち、どのホストに届き、誰が更新を支配しているかで置くべきです。

とくに企業環境では、許可した拡張機能が後から権限を増やす、提供元が変わる、利用者が未管理ブラウザで業務 SaaS へ入る、といった変化が起きやすくなります。ここを放置すると、ブラウザ拡張機能の問題は単独の便利機能ではなく、トークン窃取、フィッシング、未承認SaaS利用、管理画面アクセスの問題とつながります。したがって対策では、許可リスト、禁止権限、実行時に遮断する対象ホスト、台帳、月次レビューをまとめて回し、ブラウザを重要な業務接点として扱う運用へ寄せる必要があります。

さらに、拡張機能管理をブラウザ管理ポリシーだけの話で終わらせないことも重要です。どのログイン画面、SaaS の接点、管理画面、検証環境が外から見えているかを把握して初めて、権限の強い拡張機能が触れたときの優先順位が付けられます。つまりブラウザ拡張機能の安全管理は、権限管理、変更監視、公開面の可視化をつないだ継続運用として見るべきです。そこまで整理できると、便利さを残しながらも、業務ブラウザの危険な接点を現実的に減らしやすくなります。