Help Net Securityのインタビューで、JscramblerのCEOであるRui Ribeiro氏は、ブラウザが組織にとって制御不能なセキュリティ上の問題になっている理由を解説します。企業はデバイスも、拡張機能も、ネットワーク経路も所有していません。それにもかかわらず、顧客とのあらゆるやり取りにおいて、アプリケーションロジック、サードパーティ製コード、顧客データ、そしてAIが交わる場所こそがブラウザなのです。
同氏はコンテンツセキュリティポリシー(CSP)やサブリソース完全性(SRI)の限界、アプリケーションと同じ権限で動作するサードパーティ製AIチャットスクリプトのリスク、そして規制当局がユーザーセッション内で何が実行されたかを問う際に何を求めているかについて論じています。さらに、AIが攻撃者にとってのコスト・時間・専門知識のハードルを引き下げていると指摘します。
サーバーサイドのセキュリティはランタイムの制御に依存しています。しかしブラウザでは、デバイスも拡張機能もネットワーク経路も一切制御できません。他者の所有物であるランタイムについて、防御側はどう考えるべきでしょうか。
従来型のセキュリティは、組織が自ら所有する環境を保護できるという前提に立っています。ブラウザはその前提を覆す存在です。顧客とのあらゆるやり取りの中で、独自のアプリケーションロジック、サードパーティ製ソフトウェア、顧客データ、そして近年はAIまでもが一堂に会する場所だからです。組織はもはや、ブラウザに読み込まれるものを信頼するだけでは不十分です。どのソフトウェアが実行され、それがどのデータにアクセスでき、どのような操作を行えるのか、そしてそれらの操作が事業ポリシーに沿っているのかまで管理する必要があります。ブラウザセキュリティはもはや、クライアントサイドの脅威からWebアプリケーションを守るだけの話ではありません。顧客とのあらゆるやり取りを通じて、ソフトウェア、データ、AIが意図どおりに振る舞うことを保証する取り組みなのです。
コンテンツセキュリティポリシーは登場から10年以上が経ちます。サブリソース完全性も同様です。なぜこれらの制御策はギャップを埋められなかったのでしょうか。
CSPとSRIは今も重要なセキュリティ制御策ですが、解決する問題の性質が異なります。これらはコードの出所や改ざんの有無を検証することで、実行前の信頼を確立する役割を担います。ところが今日のリスクは、実行が始まった後に発生することが増えています。信頼されたスクリプトが動き出した後も、組織はそれがどのデータにアクセスし、どんな操作を行い、AIによってその挙動がどう変化し、最小権限の境界内で動作し続けているかを可視化する必要があります。従来型の制御策は信頼を確立するものであり、現代のブラウザセキュリティは実行そのものを統制するものなのです。
エージェント型ブラウジングは、マウスの先に人間がいるという前提を取り除きます。自律型エージェントがチェックアウト画面を進んでいくとき、最初に破綻するのは不正検知、同意取得、セッションロジックのどれでしょうか。
エージェント型AIが変えるのは、チェックアウトの流れだけではありません。攻撃の経済性そのものを根本的に変えてしまいます。かつては高度なリバースエンジニアリングの専門知識を必要とした行為が、優れたモデルにうまく練られたプロンプトを与えるだけで実現できるようになりつつあります。実際、攻撃者がAIを使ってアプリケーションロジックを瞬時に理解し、デジタル上の顧客体験を複製し、不正行為を加速させる事例はすでに確認されています。重要なのは、AIがブラウザベースのアプリケーションを侵害するために必要なコスト・時間・専門知識のハードルを引き下げているという事実を認識することです。
企業は、多くの場合サードパーティ製スクリプトによって提供されるLLMチャットウィジェットを、本番環境のページに次々と組み込んでいます。このパターンが招く、現実的に起こり得る最悪の事態とは何でしょうか。
最大のリスクは実行モデルそのものにあります。サードパーティ製のAIスクリプトは、多くの場合アプリケーションの他の部分と同じブラウザ権限で動作するため、会話の内容そのものをはるかに超えた範囲を見渡せてしまいます。適切なランタイムガバナンスがなければ、これらのスクリプトは、いかなるデータ送信が行われる前の段階で、決済情報、アカウント詳細、独自の業務フロー、価格設定ロジック、あるいはページ内の他の機密性の高い顧客データにアクセスできてしまう可能性があります。
いったんその情報がブラウザを離れ、外部のAIサービスに送られてしまうと、組織はそれがどのように処理・保持・再利用されるかを実質的に制御できなくなります。これによりプライバシー、コンプライアンス、知的財産、競争上のリスクが同時に生じることになります。
規制当局や訴訟関係者は、ユーザーセッション内で何が実行されたかを組織に証明するよう求めるケースが増えています。ほとんどの組織はそれに答えられません。実際にそれができる企業の場合、実用的な証跡とはどのようなものでしょうか。
意味のある証跡は、単にスクリプトの一覧を管理する以上のものでなければなりません。どのソフトウェアが実行されたか、どのデータにアクセスされたか、どのポリシーが適用されたか、どの挙動がブロックされたか、そしてサードパーティ製コードがセッション全体を通じて定められた権限の範囲内で動作していたかを示す必要があります。今後、組織に求められるのはブラウザ上の活動を可視化することだけでなく、顧客とのやり取りが行われている間、実際にガバナンスが遵守されていたことを裏付ける証拠を持つことになっていくでしょう。
「ブラウザは新たな境界線(エッジ)である」という主張を、ベンダーが新しいカテゴリーをでっち上げているだけだと受け取る読者もいるでしょう。ご自身の主張に対する最も強力な反論を挙げ、どのような証拠があればお考えを変えるか教えてください。
最も強力な反論は、ブラウザセキュリティは何も新しいものではない、というものです。組織はこれまでも、安全な開発手法、CSP、SRI、アプリケーションセキュリティテスト、エンドポイント保護などに頼ってクライアントサイドのリスクを低減してきました。しかし、こうした手法だけで今日の課題に十分対応できているのであれば、稼働中のブラウザセッション内を起点とするサードパーティの侵害、クライアントサイドの不正行為、プライバシー侵害、AIによるデータ漏えい、コンプライアンス違反が今もこれほど発生し続けているはずがありません。
ブラウザが急に重要になったわけではなく、その本質そのものが根本的に変化したのです。今やブラウザは、ソフトウェアが組み立てられ、機密データが生成され、AIがユーザーと交わる機会がますます増えている場所です。ブラウザセキュリティは既存の専門分野でありながら、その重要性が拡大し続けているのです。
現在のブラウザセキュリティに関する考え方のうち、3年後に誤りだったと判明する前提はどれでしょうか。
最も誤りだと判明するであろう前提は、ブラウザセキュリティが単なるアプリケーションセキュリティの取り組みに過ぎないという考え方です。ソフトウェアが実行され、データが生成され、AIが動作する場所であるがゆえに、ソフトウェアサプライチェーンのセキュリティ、データプライバシー、AIガバナンス、不正防止、コンプライアンス、デジタル上の信頼といった要素は、ますますブラウザという一点に収束していくでしょう。
ブラウザセキュリティを狭い意味でのアプリケーションセキュリティの問題として扱い続ける組織は、今や複数の経営幹部レベルの関係者にまたがるリスクへの対応に苦慮することになるでしょう。ブラウザセキュリティは今後ますます、企業全体で共有すべき経営課題になっていきます。それはブラウザ自体が変わったからではなく、企業が重視するあらゆる事柄が今やブラウザという一点で交差するようになったからです。
翻訳元: https://www.helpnetsecurity.com/2026/08/06/rui-ribeiro-jscrambler-browser-security/
