Permissions Policyの監査方法｜iframeの機能許可をヘッダーとallow属性で確認

問い合わせフォーム、地図、オンライン会議、決済画面などを外部サービスの iframe で表示すると、埋め込み先のページがカメラやマイク、位置情報を使えるかは、親ページのレスポンスヘッダーだけでは決まりません。親ページが許す範囲、各 iframe の allow 属性、埋め込み先の応答、ブラウザー側の条件を順に確認する必要があります。

設定を見ただけで監査を終えると、実際には別のオリジンへ遷移していたり、利用者の許可や HTTPS が足りなかったりして、意図した挙動とずれることがあります。機能ごとの設定と、対象ブラウザーでの許可・拒否テストを記録に残せば、必要な機能だけを特定の埋め込み先へ渡せます。

Permissions-Policy はページ全体で使える機能の上限を決め、iframe の allow 属性はその枠内で埋め込み先ごとの許可をさらに絞ります。許可対象オリジン、子ページの応答、ブラウザー対応、HTTPS、利用者の許可を別々に確かめてください。親のポリシーで無効にした機能を、子フレームから有効にはできません。

---

本記事のポイント

1. Permissions-Policyヘッダーはページで利用できる機能の上限を定め、iframeのallow属性は埋め込み先ごとにその範囲をさらに絞ります。
2. 許可対象オリジンはスキーム・ホスト・ポートの組み合わせで判定し、allowで許可リストを省略した場合はsrcのオリジンが基準になります。
3. 設定上許可されても、ブラウザー対応、HTTPSなどAPIの前提条件、利用者の許可が別に必要です。

---

Permissions Policyで制御する範囲を分ける

Permissions Policy は、ブラウザー機能のうち仕様で対象に定められたものを、どの文書で使えるか制御する仕組みです。たとえば camera、microphone、geolocation、fullscreen などが対象です。すべての Web API をまとめて制御する設定ではありません。

親ページの Permissions-Policy HTTP レスポンスヘッダーは、そのページに適用する宣言ポリシーです。ページに含まれる各 iframe にはコンテナーポリシーがあり、HTML の allow 属性で機能と許可対象を指定します。埋め込み文書自身が返すヘッダーも、その文書の機能をさらに制限できます。つまり、親ページ、iframe 要素、子ページの応答を一続きの条件として読みます。

ここでいう「許可元」は、機能の利用を認める「許可対象オリジン」を指します。オリジンはスキーム・ホスト・ポートの組み合わせです。たとえば https://meet.partner.example と http://meet.partner.example、または https://meet.partner.example:8443 は、それぞれ異なるオリジンとして扱います。同じ会社のドメインや似たサブドメインであることだけでは、同一オリジンとは判断できません。

確認する層	主に決めること	見落としやすい点
親ページのレスポンスヘッダー	ページ全体と子フレームへ渡せる機能の上限	機能ごとに既定の許可リストが異なる
iframe の allow 属性	特定の埋め込み先へ渡す機能	親の制限を広げる指定ではない
埋め込み文書とブラウザー	継承後の制限、APIの利用条件、利用者の許可	対応機能やユーザー設定によって結果が変わる

Permissions-Policy ヘッダーがない場合に、すべての機能が無効になるわけではありません。W3C の仕様では、機能ごとに既定の許可リストが定められています。* や self など機能ごとに既定値が異なるため、ヘッダーやディレクティブの欠落を「全許可」または「全拒否」と決めつけず、対象機能の既定値とブラウザーの実装を確認します。

ヘッダーとallow属性を組み合わせる

例として、親ページ自身のカメラとマイクは使わせず、親ページと地図サービスの iframe に位置情報を認める設定を考えます。HTTP レスポンスには許可する機能とオリジンを記します。

Permissions-Policy: camera=(), microphone=(), geolocation=(self "https://maps.partner.example")

この例ではカメラとマイクをすべての文書で無効にし、位置情報は親ページと https://maps.partner.example に限定しています。ヘッダーの許可対象オリジンは、ブラウザーがその機能を検討する際の上限です。必要のない機能に * を設定すると、意図しない子フレームまで利用可能な範囲が広がるため、必要な許可対象オリジンを列挙します。

地図 iframe は、必要な機能だけを allow に指定します。

<iframe
          src="https://maps.partner.example/embed/office"
          title="事業所の地図"
          allow="geolocation">
        </iframe>

現行の仕様と MDN の説明では、allow に機能名だけを書いて許可リストを省略すると、既定の許可対象は iframe の src 属性にある URL のオリジン（src）です。この例なら地図サービスのオリジンに限られます。許可対象を明示する記法もありますが、まずは src と最終的に読み込まれる文書のオリジンが一致するかを確認します。src の動的な差し替え、リダイレクト、埋め込み先の変更がある場合は、実際の遷移先まで点検してください。srcとは異なるオリジンへ遷移させる必要がある場合は、その遷移先をallowの許可リストにも明示し、親ヘッダーがそのオリジンを認めているか確認します。allow="geolocation"の省略記法だけで、別オリジンの遷移先まで自動的に許可されるとは考えないでください。

ヘッダーが geolocation=() のように位置情報を禁止していると、iframe の allow="geolocation" で覆すことはできません。親の制限を通過し、iframe の許可対象にも一致して初めて、子文書で利用できる可能性が生まれます。さらに子文書自身のヘッダー、ブラウザーの機能対応、APIごとの利用条件が残ります。MDN も allow 属性はヘッダーポリシーの上に追加される制限であり、置き換えではないと説明しています。

外部 iframe 自体の提供者、送信データ、停止条件を整理するには、企業サイトの外部スクリプト棚卸しも役立ちます。ここではその棚卸しのうち、ブラウザー機能をどの埋め込み先へ渡すかに範囲を絞ります。

5段階で設定と実際の挙動を照合する

1. ページ内のiframeと機能要件を一覧にする

ソースに書かれた iframe だけでなく、タグ管理ツール、チャット、予約・決済サービス、JavaScript で後から挿入される要素も対象にします。各行に親ページの URL、iframe の src、読み込み後の最終 URL、提供者、必要な機能、利用目的、業務責任者を記録します。camera や microphone が必要な理由が説明できない埋め込みは、機能を許可しない状態から確認します。機能を使わない場合も、allow属性を省略するだけで無効になるとは限りません。機能ごとの既定値を確認し、不要な機能は上位ヘッダーの空の許可リスト（例：camera=()）などで明示的に拒否します。

2. 親ページの実レスポンスを確認する

Webサーバー、CDN、ホスティング設定を確認したあと、ブラウザーの開発者ツールで親ページの実際の GET レスポンスヘッダーを確認します。設定ファイルに値があっても、別の配信経路、リダイレクト、ページ単位の上書きによって本番レスポンスが異なることがあります。対象機能について、許可されるオリジン、拒否するオリジン、ディレクティブの欠落、* の使用を一覧化します。設定前後のレスポンスを記録すれば、公開後に配信設定が戻った場合も比較できます。

3. iframeごとのallowとsrcを照合する

HTML と実行時の DOM を見比べ、必要な機能だけが allow に含まれるか確認します。allow="camera; microphone; geolocation" のような一括許可が必要かを機能ごとに問い直し、映像会議に地図の位置情報を含めるなど、用途の異なる許可を同じ iframe に混ぜないようにします。属性の値だけでなく、許可対象オリジンを src および遷移先と照合し、入れ子になった iframe ではすべての祖先から許可が継承されるかを確認します。

4. 子ページの応答と別の制限を確認する

埋め込み先のレスポンスヘッダー、最終 URL、リダイレクト、さらにその子にある iframe を確認します。親の許可があっても、子ページ自身の Permissions-Policy が機能を止める場合があります。また sandbox 属性、CSP、ブラウザーの追跡防止や拡張機能は別の制限です。これらは Permissions Policy と役割が異なるため、コンソールにエラーが出たときは、どの層で拒否されたかを分けて調べます。CSP の配信元を段階的に点検する方法は、CSP Report-Onlyの運用手順を参照してください。

5. 対象ブラウザーで許可と拒否を試す

本番相当の HTTPS 環境で、許可した iframe と許可していない iframe の両方を試します。ブラウザーの開発者ツールでヘッダー、iframe の読み込み先、コンソールの拒否理由を確認し、許可した機能では API を実行できるか、拒否した機能では実行できないかを記録します。利用者が以前に許可していると確認画面が再表示されないため、「プロンプトが出ない」を「許可されていない」と判断しないでください。可能なら新しいプロファイルまたは権限をリセットしたテスト環境でも再確認します。

監査結果はブラウザー名とバージョン、OS、親・子の URL、HTTP レスポンス、ポリシー値、操作した利用者権限、許可時と拒否時の結果を一組で残します。MDN は Permissions-Policy ヘッダーを Baseline に含めていません。W3C 仕様も、ユーザーエージェントがすべての制御対象機能を実装する義務を負うとはしていません。機能名が仕様に載っていることだけで、対象ブラウザーで同じ動作になると決めつけず、実際の利用環境ごとに検証します。

ポリシー以外の条件と例外を記録する

Permissions Policy で機能の利用が許されても、それだけでカメラや位置情報が使えるわけではありません。getUserMedia() は安全なコンテキスト（通常は HTTPS、開発時の localhost など）で使う API で、利用者の許可が必要です。Geolocation API も安全なコンテキストと利用者の許可を要します。利用者が拒否した場合、端末に機器がない場合、OS の設定で利用できない場合にも動作しません。ポリシーの許可、セキュアコンテキスト、ブラウザー対応、利用者許可を別々の確認欄にします。

実務では例外ごとに、許可する機能、許可対象オリジン、埋め込み先と親ページ、業務上の理由、承認者、実測したブラウザー、代替手段、見直し期限を記録します。サービス変更やドメイン変更があったときは再テストし、使わなくなった iframe と許可を同時に削除します。許可を一時的に広げた場合も、作業後に元の制限へ戻ったことを本番レスポンスで確認します。

Permissions Policy は URL の Referer 送信範囲を制御しません。外部への URL 情報の送信は、Referrer-Policyの設定と通信実測で別に監査します。また、外部スクリプトの所有者や送信データを把握する棚卸しと、iframe の機能許可は別の管理項目です。例外を最小限にする考え方は Privacy by Designとも結び付けられますが、実際のブラウザー設定・ユーザー許可の代替にはなりません。

よくある質問

Permissions-Policyヘッダーがないページでは、iframeの機能はすべて拒否されますか？

一律には拒否されません。各機能には仕様上の既定の許可リストがあり、既定値は機能ごとに異なります。対象ブラウザーの実装も影響します。安全側に動かしたい機能は、ヘッダーと iframe 属性で必要な範囲を明示し、実際のレスポンスと挙動を確認してください。

iframeのallow属性だけでカメラや位置情報を許可できますか？

allow属性を書くだけでは利用できるとは限りません。親側で明示的に禁止されておらず、継承されるポリシーや機能の既定値が許す場合は、ヘッダーを追加せずallowで委譲できることもあります。一方、親が禁止した機能は復活できません。子ページのポリシー、ブラウザー対応、HTTPS、利用者の許可も確認してください。

ポリシーで許可すれば、利用者の許可なしにカメラを起動できますか？

できません。カメラ・マイクを利用する getUserMedia() では安全なコンテキストに加えて、利用者の許可が必要です。利用者が拒否すれば API は使えません。Geolocation API も別途、利用者への許可を必要とします。Permissions Policy は利用者の選択を置き換えません。既に利用者の許可が保存されている場合は、新たな確認画面が出ないことがあります。確認画面の表示と、利用者の許可があることは分けて判断します。

同じ会社ドメインのiframeなら、許可対象としてまとめてよいですか？

ドメインの所属ではなく、スキーム・ホスト・ポートを比較します。サブドメインが違う場合や HTTP と HTTPS が異なる場合、ポートが異なる場合は別オリジンです。まず実際の src とリダイレクト後の URL を調べ、その iframe で必要なオリジンだけを許可します。

エラーが出たとき、Permissions Policyで拒否されたと判断できますか？

エラーだけで原因を特定できないことがあります。ポリシー、利用者の拒否、HTTPS 不足、ブラウザー非対応、sandbox、OS の機器設定などで似た失敗が起こり得ます。許可する条件と拒否する条件を対にして試し、親ページと iframe のレスポンス、コンソール、利用者の権限状態を照合してください。

関連ページと関連記事

埋め込み機能の許可範囲を点検する