公開日
あなたのブラウザ拡張は本当に安全？ 開発者の“本音”から探る3つの落とし穴
ブラウザの利便性を飛躍的に向上させる拡張機能。その開発に携わる中で、「自分の書いたコードは、本当にユーザーのセキュリティやプライバシー（以下、S&P）を守れているのだろうか？」という不安を感じたことはありませんか？その不安は、決してあなただけのものではありません。
本記事は、CISPA Helmholtz Center for Information Securityの研究者たちが発表した論文「“I have no idea how to make it safer”: Studying Security and Privacy Mindsets of Browser Extension Developers」に基づいています。この研究は、21人の現役拡張機能開発者への詳細なインタビューとコーディングタスクを通じて、「どうすればもっと安全にできるか分からない」という開発者のリアルな悩みと、その根本原因を明らかにしました。
図表1：開発者のS&P意識に関連するテーマのマインドマップ
あなたのコードにも潜む？コーディングで判明した3つの落とし穴
「S&Pは重要だ」という意識とは裏腹に、実際のコーディングでは意図せず脆弱性を生んでしまうことがあります。研究で実施された2つのコーディングタスクから、開発者が陥りがちな3つの具体的な落とし穴を見ていきましょう。
1. データ保存：「プライベートな保存先」を選んだつもりが… API選択の罠
最初のタスクは、ユーザーの住所情報を拡張機能内に保存するというシンプルなものでした。このタスクでは、参加した開発者の多くが、プライバシー保護機能を持つ拡張機能専用のAPI（storage.syncまたはstorage.local）を正しく選択しました。
しかし、その選択理由を尋ねると、「デバイス間で同期できて便利だから」といった機能面が主であり、ウェブサイト側からアクセスを隔離できるという重要なプライバシー上の利点を理解しているわけではありませんでした。さらに代替案として、ウェブサイトのスクリプトからもアクセス可能なlocalStorageを挙げる開発者もおり、開発者が機能的な類似性からAPIを選んでしまい、S&Pの観点を見落としがちであることが示唆されました。
2. 外部サイトの埋め込み：そのヘッダー削除、本当に安全ですか？
2つ目のタスクは、外部サイト（Amazon.com）をiframeで安全に埋め込むという、より複雑なものでした。これを妨げるHTTPヘッダー（X-Frame-Options）に、Manifest V3のルール内でどう対処するかが問われました。
多くの開発者はHTTPヘッダーの変更に漠然とした危険性を感じていましたが、その対処法の知識は乏しいのが実情でした。重要なのは、ヘッダーを「どう」変更するかというプロセスの違いです。
Manifest V3では、拡張機能に過剰な権限を与えず、事前に定義したルールに基づいてブラウザ自身が安全に操作を行うdeclarativeNetRequest APIの使用が推奨されます。しかし、この知識がないと、Stack OverflowやChatGPTで見つけた古い情報に基づき、拡張機能にすべての通信を監視・変更できる強力な権限を与えてしまう、危険な実装を選びかねません。
結果的に外部サイトは表示されても、そのプロセスには大きなリスクの差が生まれます。最新の安全なAPIに関する知識不足が、意図せず脆弱性を生み出す典型的なパターンと言えるでしょう。
3. パーミッション設定：「念のため許可」に潜む、過剰権限のリスク
拡張機能の権限設定は、ストアの審査にも関わる重要なポイントです。インタビューでは、ほとんどの開発者が「最小権限の原則」を意識していると語りました。
ところが、タスクで提供されたサンプルコードのmanifest.jsonファイルに、意図的に冗長な権限（例：<all_urls>）を仕込んでおいたところ、これに気づいて指摘できた開発者は半数以下でした。この意識と行動の乖離は、開発者がAPIパーミッションには注意を払う一方で、ホストパーミッションなど他の設定については見過ごしがちであることを示しています。
脆弱性が生まれる3つの背景。開発者を縛る“エコシステム”の壁
なぜ、開発者はS&Pの重要性を認識しながらも、脆弱な拡張機能を生み出してしまうのでしょうか。その原因は個人のスキルだけでなく、開発者を取り巻く「エコシステム」そのものにありました。
1. 「儲からない」という現実：セキュリティ対策を後回しにさせる経済的要因
多くの開発者にとって、拡張機能開発は直接的な収益に結びつきにくいのが現実です。研究参加者からは、「機能が少ない拡張機能ではユーザーが集まらず、収益も生まれない。しかし、機能を豊富にすればインフラコストがかかる」という声が上がりました。S&P対策に十分な時間やコストをかける金銭的なインセンティブが不足していることが、対策を後回しにさせる一因となっています。
2. 「理不尽だ」という不満：開発者を疲弊させるプラットフォームの現状
GoogleやMozillaといったプラットフォームの存在は不可欠ですが、その運営方針が開発者を悩ませています。特に、拡張機能の審査プロセスは「ブラックボックス」だと多くの開発者が感じており、審査基準の不徹底やリジェクト理由の不明確さが、開発者を疲弊させています。また、Manifest V3のような大きな仕様変更が、開発者の意見を十分に聞かずにトップダウンで進められることへの不満も根強くあります。
3. 「情報が足りない」という叫び：頼りの公式ドキュメントと外部情報の危うさ
開発者が最も信頼するべき情報源は、プラットフォームが提供する公式ドキュメントです。しかし、研究では「特定のAPIを使用した場合のS&P上のリスクや利点」といった重要な情報が不足していると指摘されています。結果として、開発者はStack OverflowやAI、個人のブログ記事といった外部の情報に頼らざるを得ず、その情報の質や新しさが、拡張機能の安全性に直接影響してしまうという危険な状況が生まれています。
結論：より安全な拡張機能エコシステムを築くために
本研究は、拡張機能のセキュリティ問題が、開発者個人の課題と、彼らを取り巻くエコシステムの課題という、二つの側面から成り立っていることを示しています。この状況を改善し、ユーザーが安心して使える拡張機能を生み出していくために、私たちに何ができるのでしょうか。論文では、以下の点が提言されています。
- 脅威を意識する: 自身の拡張機能がどのような攻撃を受ける可能性があるのかを具体的に想定し、それに対する防御策を積極的に検討することが重要です。
- S&Pと利便性のトレードオフを考える: 新機能を実装する際には、それがもたらす利便性と、S&P上のリスクを天秤にかけ、慎重に判断する習慣をつけましょう。
- 積極的に声を上げる: プラットフォームのポリシー変更やドキュメントの不備など、開発環境の改善を求める正当な懸念については、ベンダーに対して積極的にフィードバックを送りましょう。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: