なぜ今、Permissions-Policyなのか？XSSの「その先」を封じる防壁論
現場でインシデント対応をしていると、XSS（クロスサイトスクリプティング）を「単なるアラート表示の脆弱性」と甘く見ているエンジニアに時折出会う。だが、現代の攻撃者はそんなに甘くない。彼らにとってXSSは、「ブラウザという名の端末を遠隔操作するための踏み台」に過ぎないんだ。
もし君のアプリがXSSを許したとき、攻撃者はユーザーのセッションを盗むだけでなく、PCのカメラを勝手に起動して覗き見したり、位置情報を特定したりする可能性がある。これを防ぐのが、今回解説する Permissions-Policy だ。
1. 攻撃者が狙う「盲点」：XSSの先にある権限悪用
例えば、攻撃者が仕込んだスクリプトがブラウザのカメラやマイクの権限を要求したらどうなるか。PoC（概念実証）のコードは極めて単純だ。
// 攻撃者がインジェクションするスクリプトの例
// ユーザーの許可を待たずにデバイス情報やカメラへのアクセスを試みる
navigator.mediaDevices.getUserMedia({ video: true })
.then(stream => { / 攻撃者のサーバーへストリームを転送する処理 / })
.catch(err => console.error(“Access denied”));
もしユーザーが一度でも権限を許可したことがあるサイトなら、XSSを通じてバックグラウンドでカメラが起動する。これに対する防御策として、CSP（Content Security Policy）は有名だが、機能そのものをブラウザレベルで「物理的に遮断」する Permissions-Policy は、多層防御の要となる。
2. Permissions-Policyの設計思想：最小権限の原則
Permissions-Policy は、HTTPレスポンスヘッダーを通じて、ブラウザに「このサイトではこの機能は絶対に使うな」と命令するものだ。
推奨する設定値の考え方
Webアプリでカメラやマイクを常用しないのであれば、「全て拒否（None）」から始めるのが鉄則だ。
camera=(): カメラ利用を禁止microphone=(): マイク利用を禁止geolocation=(): 位置情報取得を禁止payment=(): 決済APIの利用を禁止
3. 実装サンプル：コピペで使える設定ガイド
設定はWebサーバーのレスポンスヘッダーで行うのが最も確実だ。
Nginx の場合 (nginx.conf)
全ての機能をデフォルトで無効化し、必要なものだけを明示的に許可する構成
add_header Permissions-Policy “camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()”;
PHP の場合 (index.php または共通ヘッダーファイル)
Express (Node.js) の場合
app.use((req, res, next) => {
res.setHeader(‘Permissions-Policy’, ‘camera=(), microphone=(), geolocation=(), payment=()’);
next();
});
4. 運用上の注意点と「ハマりどころ」
このポリシーを導入する際、最も怖いのは「突然、正当な機能が動かなくなること」だ。特に自社でWeb会議ツールを作っている場合や、地図表示（Google Maps APIなど）を使っている場合は注意が必要だ。
もし特定のドメインだけ許可したい場合は、以下のように記述する。
Permissions-Policy: camera=(self “https://trusted-partner.com”)
※ self は自ドメインを指す。
現場からのアドバイス：デバッグのコツ
設定を適用した直後は、ブラウザの「検証ツール（DevTools）」の「コンソール」を確認してほしい。権限がブロックされた場合、ブラウザがエラーメッセージを吐き出してくれる。いきなり本番環境に入れるのではなく、まずは Permissions-Policy: ...; report-to=... を使って、ブロックが起きた際にレポートを送信するように設定し、影響範囲を調査する「Report-Only」に近い運用を強く推奨する。
最後に：セキュリティは「諦めない」こと
XSSを完全に防ぐことは至難の業だ。どんなに優れたエンジニアでも、複雑な動的サイトにおいて全ての入力値をサニタイズし切ることは限界がある。
だからこそ、「XSSが起きたとしても、カメラを盗まれたり、不正な支払いが行われたりするリスクを限りなくゼロにする」という、この多層防御の姿勢が重要なんだ。
「たかがヘッダー設定」と侮るな。この一行が、未来のインシデントからユーザーのプライバシーを守る決定打になる。今すぐ自社のレスポンスヘッダーを確認し、不要な権限を全て封じておいてくれ。それが君のアプリを「信頼されるプロダクト」にするための、プロとしての責任だ。
コメント