境界防御の終焉：Permissions-PolicyでXSSの「牙」を抜く
セキュリティ・アーキテクト諸君、ご苦労様。WAFやCSP（Content Security Policy）を導入して「守りは完璧だ」と高を括っているなら、今すぐその認識を改めたほうがいい。
現代のWebアプリケーションにおいて、XSS（Cross-Site Scripting）は死滅していない。それどころか、JavaScriptの実行環境（ブラウザ）は、もはや単なるレンダリングエンジンではなく、マイク、カメラ、位置情報、GPUアクセラレーションといった「実世界の物理的リソースへのゲートウェイ」と化している。
反射型だろうが、格納型だろうが、あるいは高度なDOM型だろうが、攻撃者が目指すのはスクリプトの実行そのものではない。「実行したスクリプトを用いて、どれだけのリソースを奪取できるか」だ。今日は、攻撃者が足場を確保した後の「被害の極小化」における最終防衛線、Permissions-Policyの深淵に触れる。
—
1. XSSのパラダイムシフトと「権限」の重要性
かつてのXSSは「セッションクッキーの窃取」が主目的だった。しかし、HttpOnly属性の普及により、それは難易度が増した。今、攻撃者が狙うのは「ユーザーのコンテキストそのもの」だ。
もし、貴方のWebアプリが位置情報APIを許可していれば、XSSが成功した瞬間にユーザーの現在地が攻撃者のサーバーに送信される。カメラが許可されていれば、DOM要素の操作からWebRTCを悪用した盗撮すら可能だ。
CSP（Content Security Policy）は「どこからスクリプトを読み込むか」を制御するが、Permissions-Policyは「ブラウザが提供する強力なAPIを、どのドメインが利用可能か」を根本から制限する。これは、万が一脆弱性によりスクリプトが注入された際、そのスクリプトに「目（カメラ）」や「耳（マイク）」を与えないための、極めて強力なサンドボックス化戦略だ。
—
2. Permissions-Policyのアーキテクチャ設計
このヘッダーは、ブラウザに対する一種の「拒絶命令」だ。デフォルトで全てを拒否し、必要な機能だけをホワイトリスト化する。これがセキュリティの鉄則である。
推奨されるベースライン実装
以下は、一般的なWebアプリケーションにおいて適用すべき厳格なポリシー設定だ。
サーバーサイドで設定するHTTPレスポンスヘッダーの例
デフォルトで全てを無効化し、特定の機能のみを許可する（または自ドメインのみに制限）
Permissions-Policy:
camera=(), # カメラ利用を完全に禁止
microphone=(), # マイク利用を完全に禁止
geolocation=(), # 位置情報取得を禁止
payment=(self), # 支払いAPIは自ドメイン内のみ許可
usb=(), # USBデバイスアクセスを禁止
interest-cohort=() # GoogleのFLoC/Topicsを無効化（プライバシー保護）
なぜこれが「耐量子時代」を見据えた戦略なのか
少しメタな話をしよう。将来的に計算機能力が飛躍的に向上し、現在の暗号プロトコルが揺らいだとき、防御のレイヤーは「複雑な暗号」から「OSとブラウザのプリミティブな機能制限」へと回帰する。物理的リソースへのアクセスを制御するポリシーは、攻撃者の実行環境を極限まで矮小化する。AIが生成する高度なポリモーフィック・コードであっても、OSが「カメラへのアクセス権がない」と判断すれば、そのペイロードは単なる無害なメモリ消費に過ぎなくなるからだ。
—
3. 実務的な監査ポイントと注意点
この設定を本番環境に投入する際、開発チームが陥りやすい罠がある。
1. サードパーティライブラリの断絶: 埋め込んでいる解析ツールや広告スクリプトが、意図せず位置情報を取得しようとして失敗し、画面が真っ白になるケースだ。Permissions-Policyを導入する際は、必ずCSPのreport-uriと同様に、監視体制を整える必要がある。
2. iFrameの扱い: allow属性との連動を忘れてはならない。iframeタグ側で権限を委譲しない限り、親ページが許可していても、埋め込みコンテンツはブラウザのAPIを利用できない。
—
結びに代えて：泥臭い防御の積み重ね
「セキュリティは魔法ではない」と、私はいつも現場のエンジニアに伝えている。
最新のAIプロンプトインジェクションに対する防御層（ガードレイル）の設計においても、根本的な思想は同じだ。入力されたプロンプトがどれだけ巧妙であっても、その出力先であるAPIが「権限」という鎖で縛られていれば、被害は局所的に留まる。
Permissions-Policyは、単なるヘッダー設定ではない。これは、貴方のアプリケーションが「何をすべきで、何をすべきでないか」をブラウザという最強の実行プラットフォームに明示する、セキュリティアーキテクトとしての契約書だ。
今日から、ヘッダーログを確認してほしい。不必要な権限が野放しになっていないか？ その隙間こそが、次のCVEが潜り込む場所だ。
インシデントは起きてから対処するものではない。起きないように構造をハックする。それが、我々エンジニアの矜持だ。
コメント