ブラウザの「制御権」を取り戻せ：Permissions-Policyが防ぐ静かなる乗っ取り
セキュリティアーキテクトとして、我々が日々向き合っているのは「脆弱性のパッチ」だけではない。ブラウザという、もはやOSと同等の複雑性を持つ巨大な実行環境において、「本来あるべき機能の不正な行使」をどう阻止するかという、いわば権限分離（Privilege Separation）の戦いだ。
特に `Permissions-Policy`（旧 Feature-Policy）は、過小評価されがちな防御の要である。これは単なる「設定ファイル」ではない。Webアプリケーションの実行コンテキストにおける「攻撃対象領域（Attack Surface）の物理的な削減」そのものだ。
なぜ、Permissions-Policyが「最後の砦」なのか
攻撃者は、XSS（Cross-Site Scripting）やサプライチェーン攻撃によるサードパーティスクリプトの混入に成功した際、次に何を狙うか。彼らはブラウザが提供する強力なAPIを悪用し、情報を吸い上げる。
- カメラ・マイクの権限搾取: ユーザーに気づかれずに背後で録画・録音。
- Geolocationの悪用: 物理的な位置の特定。
- Sync-XHRの強制: メインスレッドを止め、攻撃の痕跡を消すためのUIフリーズ。
- Payment APIの不正操作: 金銭的被害への直結。
これらはすべて「ブラウザが許可している機能」であり、アプリケーション層のコードが改ざんされた場合、たとえCSP（Content Security Policy）で外部ドメインからのスクリプト実行を制限していても、埋め込まれた悪意あるコードには防げない。そこで、ブラウザのカーネルに近いレベルで「その機能へのアクセス権」そのものを無効化するのが `Permissions-Policy` だ。
実践的アーキテクチャ：堅牢なHTTPヘッダー設計
単に「何でも許可する」というデフォルト設定は、現代のWebアプリケーションにおいて論外である。我々が構築すべきは、「最小特権の原則」をブラウザ実行環境にまで適用したポリシーだ。
以下に、高セキュリティを謳うモダンなWebサービスにおける推奨設定例を示す。
Permissions-Policy ヘッダー設定例
自分のドメインのみに機能を制限し、サードパーティの悪用を封じる
Permissions-Policy:
camera=(),
microphone=(),
geolocation=(self),
payment=(self “https://checkout.trusted-partner.com”),
usb=(),
display-capture=(),
interest-cohort=()
この設定が意味する「防衛ロジック」
- `camera=(), microphone=()`: 空のリストは「いかなるオリジンにも許可しない」ことを明示する。攻撃者がXSSに成功しても、`navigator.mediaDevices.getUserMedia` を呼び出した瞬間にブラウザレベルで拒絶される。
- `geolocation=(self)`: 地図アプリのように自社ドメインのみが位置情報を使えるように制限する。サードパーティの広告スクリプトが混入しても、位置情報を盗み出すことは不可能だ。
- `interest-cohort=()`: GoogleのFLoC（現在はTopics API等に移行しているが）のようなトラッキング系機能を明示的に無効化し、プライバシー保護と攻撃経路の遮断を両立する。
プロンプトインジェクションと「ブラウザ機能」の交差点
最近のインシデントハンドリングで興味深いのは、生成AIを組み込んだWebアプリでの「プロンプトインジェクション」と、ブラウザAPIの悪用の組み合わせだ。
もしあなたのWebアプリが、AIの出力結果をそのままDOMにレンダリングする構造（例: `innerHTML` への代入など）を持っていた場合、攻撃者はAIを操作して「隠れたiframeを生成し、カメラへのアクセス許可をユーザーに強要する」といったシナリオを描ける。
ここで `Permissions-Policy` が有効なのは、AIが生成した悪意あるiframeであっても、親コンテキストで制限をかけていれば、そのiframeはカメラ APIを物理的に呼び出せないからだ。 これは、ガードレイルの設計において非常に重要な「多層防御」の考え方である。
今後の監査とアーキテクチャの進化
我々プロフェッショナルは、このヘッダーを設定して満足してはならない。CI/CDパイプラインにおいて以下の監査を組み込むべきだ。
1. 静的解析: デプロイ前にヘッダーの存在と、`camera` や `microphone` が “（ワイルドカード）になっていないかをLinterで検知する。
2. 動的解析（DAST）: PlaywrightやPuppeteerを用いたE2Eテストで、意図的にブラウザAPIを呼び出し、`NotAllowedError` が適切にスローされるかを確認する。
最後に：セキュリティは「諦め」の積み重ねである
セキュリティアーキテクトとして言わせてもらえば、「アプリの全機能が全権限を持つ必要はない」という事実を直視することだ。機能を捨てる勇気、そして制御下に置く知見こそが、今日の複雑なWeb攻撃を無力化する。
ブラウザを単なる「表示エンジン」と考える時代は終わった。我々は、ブラウザという「OS」に対して、厳格なカーネルレベルの制約を課す必要がある。その第一歩が、この `Permissions-Policy` の徹底だ。
次は、これをどうやって CSP の `script-src` 制限と組み合わせ、ゼロトラストな実行環境をブラウザ内部に構築するかを深掘りする必要があるだろう。だが、まずはこの設定を今すぐ反映させることだ。それが、我々エンジニアの責務である。
コメント