Permissions-Policy とは？推奨設定と書き方
目次
この記事でわかること
- Permissions-Policy が「ブラウザの強力な機能を許可リストで制御する」仕組みであること
- 制御できる主な機能（camera / microphone / geolocation 等）
- Feature-Policy（旧仕様）との違いと移行
- 推奨設定（使わない機能を全部止める）
Permissions-Policy はブラウザ機能の許可リスト
ブラウザは現代では非常に多くの機能を持ちます: カメラ・マイク・位置情報・USB デバイス・支払い API・全画面表示などなど。これらは便利ですが、悪意あるサードパーティスクリプトが iframe 経由で勝手に有効化したら大変です。
Permissions-Policy は、レスポンスヘッダで「このページとこのページ内 iframe で、ブラウザのどの機能を使ってよいか」を許可リスト形式で宣言します。
Permissions-Policy: camera=(), microphone=(), geolocation=()
この例は「カメラ・マイク・位置情報は どこからも使わせない」という宣言です。仮にサードパーティスクリプトが navigator.mediaDevices.getUserMedia() を呼んでも、ブラウザが拒否します。
制御できる主な機能
カテゴリ別に整理:
プライバシー系（特に重要）
cameraカメラmicrophoneマイクgeolocation位置情報clipboard-read/clipboard-writeクリップボード読み書き
デバイス系（使う場面はほぼない）
accelerometer/gyroscope/magnetometer各種センサーusb/serial/bluetooth物理デバイス連携hidHID デバイス
表示・支払い系
fullscreen全画面表示picture-in-picturePinPautoplay動画自動再生paymentWeb Payment APIscreen-wake-lockスリープ防止
「使う予定が明確にないものは全部止める」のが安全です。
Feature-Policy（旧仕様）との違い
Permissions-Policy は Feature-Policy（旧仕様）の後継です。両者は構文が異なります。
# 旧仕様 Feature-Policy（非推奨）
Feature-Policy: camera 'none'; microphone 'self'
# 新仕様 Permissions-Policy（推奨）
Permissions-Policy: camera=(), microphone=(self)
主要ブラウザは両方をサポートしていますが、新規導入は Permissions-Policy 一択です。すでに Feature-Policy を設定している場合は移行を推奨します。
値の書き方
() 空括弧 = どこからも禁止
camera=()
最も厳格。ページ自身でも iframe 経由でもカメラは使えない。
(self) = 自社オリジンのみ許可
camera=(self)
自社ドメインのスクリプトはカメラを使えるが、iframe で埋め込んだ第三者ドメインは使えない。
特定ホストのみ許可
camera=(self "https://trusted.example.com")
自社 + 特定パートナーのみ。URL は HTTP Structured Fields（RFC 8941）の仕様上、必ずダブルクォートで囲んだ String 型として記述します。クォートを忘れると主要ブラウザがパースに失敗し、ヘッダ全体が無視されて制限が効かなくなる事故が起きます。self と * はトークンなのでクォート不要。
* 全許可（非推奨）
camera=*
どこからでも使える。機能制御の意味がないので避ける。
推奨設定
「使う予定が明確にないものは全部止める」が現実解です。コーポレートサイトや LP では:
Permissions-Policy:
camera=(),
microphone=(),
geolocation=(),
payment=(),
usb=(),
serial=(),
bluetooth=(),
hid=(),
accelerometer=(),
gyroscope=(),
magnetometer=(),
midi=()
これで「サードパーティ広告 SDK が iframe 経由で位置情報を取ろうとする」「悪意あるスクリプトがマイクを起動しようとする」等のシナリオを根絶できます。
例外
サイトで明示的に使う機能だけ (self) で許可:
- 動画ミーティング機能あり →
camera=(self), microphone=(self) - 店舗検索機能あり →
geolocation=(self) - EC で Web Payment API 使用 →
payment=(self)
サーバー別の設定例
Cloudflare（Transform Rules）
ダッシュボード → Rules → Transform Rules → Modify Response Header
- Header name:
Permissions-Policy - Value:
camera=(), microphone=(), geolocation=()
Nginx
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;
WordPress（.htaccess）
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
iframe 単位の制御
iframe 個別に許可を上書きすることもできます（allow 属性）:
<iframe src="https://video.example.com" allow="camera; microphone"></iframe>
ヘッダで許可されていても、iframe で allow を指定しないと iframe 内では使えない、という設計です。
まとめ
- Permissions-Policy はブラウザの強力な機能（カメラ / マイク / 位置情報 等）の許可リスト
- Feature-Policy（旧）は非推奨、新規導入は Permissions-Policy
- 推奨は「使う予定がない機能は全部
()で禁止」 - iframe 単位の
allow属性とも連携する
まずは現状を把握しましょう
自社サイトに Permissions-Policy が設定されているかは、無料の Web セキュリティヘッダ 単発チェック で 30 秒で確認できます。
SSL や HSTS など Permissions-Policy 以外のセキュリティヘッダ全体を 日本語で逐語解説 してほしい場合は、SSL 設定 読み解きツール もどうぞ。「これは何？」「なぜ重要？」「次の打ち手は？」までセットで表示します。設定支援が必要な場合は Web セキュリティヘッダ診断＋設定支援（3 万円〜）でご相談ください。
CSP の入門は CSP（Content-Security-Policy）とは？Web 担当者のための入門、HSTS は HSTS の設定方法、X-Frame-Options は クリックジャッキング対策、Referrer-Policy は Referrer-Policy のおすすめ設定値 を参照してください。Permissions-Policy と CSP の役割の違いは Permissions-Policy と CSP の違い で整理しています。
総合点検は 無料のドメイン診断、SSL 単独は SSL 単発チェック をご利用ください。