Permissions-Policy と CSP の違い
目次
「Permissions-Policy と CSP（Content-Security-Policy）、名前は似ているけれど何が違うの」。セキュリティヘッダを調べ始めた Web 担当者がまず引っかかるのがこの 2 つの区別です。どちらも HTTP レスポンスヘッダで、どちらもサイトを安全にするためのもの。ですが、守る対象も、効く攻撃も、まったく異なります。
結論を先に言うと、両者は競合する選択肢ではなく、役割分担して併用するものです。この記事では、それぞれが何を制御し、どんな問題を防ぐのか、そして実際の設定例までを整理します。
Permissions-Policy と CSP は守る対象が違う
一番大事なポイントは、2 つのヘッダが見ている「場所」が違うことです。
CSP（Content-Security-Policy）が見ているのは、ページが読み込むコンテンツ（リソース）です。スクリプト、スタイルシート、画像、フォント、外部への通信先など、「どこから何を読み込んでよいか」「どのスクリプトを実行してよいか」をブラウザに指示します。許可していない出どころのスクリプトはブラウザがブロックします。
一方の Permissions-Policy が見ているのは、ページが使えるブラウザの強力な機能（API）です。カメラ、マイク、位置情報（geolocation）、決済 API、全画面表示など、ユーザーのプライバシーや端末に深く関わる機能を「このページで使ってよいか」単位で許可・拒否します。
たとえるなら、CSP は「建物に出入りできる業者と荷物を制限する受付」、Permissions-Policy は「カメラや金庫など特定設備のスイッチを管理する権限表」です。受付と設備管理は別の仕事であり、片方があればもう片方が要らない、という関係ではありません。
それぞれの基礎をもっと丁寧に知りたい場合は、まず Permissions-Policy とは で個別機能の制御の考え方をつかんでおくと、この後の併用の話が理解しやすくなります。
CSP はコンテンツとスクリプト実行を制御して XSS を防ぐ
CSP の主目的は、クロスサイトスクリプティング（XSS）の被害を抑えることです。
XSS は、攻撃者が用意した不正なスクリプトを何らかの形でページに紛れ込ませ、訪問者のブラウザ上で実行させる攻撃です。入力フォームやコメント欄を経由して埋め込まれることが多く、放置するとセッション情報の盗難やページ改ざんにつながります。
CSP は「許可した出どころのスクリプトしか実行しない」とブラウザに約束させることで、たとえ不正なスクリプトがページに混入しても、それが実行される前にブロックします。混入そのものを防ぐのはアプリ側の対策ですが、CSP は最後の防波堤として働きます。
CSP は複数の指示（ディレクティブ）をセミコロン（;）区切りで並べて記述します。代表的なものは次のとおりです。
default-src: 他の指示がない場合の既定の読み込み元。すべての種類の土台になるscript-src: JavaScript の読み込み・実行を許可する出どころstyle-src: CSS の読み込みを許可する出どころimg-src: 画像の読み込みを許可する出どころconnect-src: fetch や WebSocket など、通信先を許可する出どころframe-ancestors: 自サイトを iframe に埋め込んでよい相手。クリックジャッキング対策に効く
基本となる設定例は次のようになります。
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com
これは「リソースは原則として自サイト（'self'）からのみ。ただしスクリプトに限り、自サイトと信頼する CDN からの読み込みも許可する」という意味です。'self' は同一オリジン、'none' を指定するとその種類を完全にブロックできます。
なお frame-ancestors を併せて指定すれば、他サイトに自社ページを iframe で勝手に埋め込まれ、ボタンを誤クリックさせられるクリックジャッキングも防げます。CSP は XSS だけでなく、こうした埋め込み系の攻撃にも効く守りの広いヘッダです。
Permissions-Policy はブラウザ機能の利用可否を制御する
Permissions-Policy が守るのは、コンテンツではなくユーザーの端末とプライバシーです。
カメラ、マイク、位置情報といった機能は便利な反面、悪用されれば盗撮・盗聴・追跡につながります。とくに自サイトが外部の広告やウィジェットを iframe で読み込んでいる場合、その埋め込みコンテンツが勝手にカメラや位置情報を要求してくる可能性があります。Permissions-Policy は「このページとその中の埋め込みでは、どの機能を使ってよいか」を出どころ単位で線引きします。
記述は機能名と許可リストの組で、カンマ（,）区切りで複数並べます。許可リストの書き方は次のとおりです。
(): その機能をすべての文脈で無効化する（一切使わせない）(self): 同一オリジンのページでのみ許可する("https://example.com"): 指定した出どころにのみ許可する*: すべての出どころで許可する
たとえば、カメラとマイクは一切使わず、位置情報は自サイトでのみ使う設定はこう書きます。
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
カメラ機能を使わないサイトであれば camera=() と明示しておくことで、万一不正なスクリプトや埋め込みがカメラ起動を試みても、ブラウザがその要求自体を拒否します。使わない機能を最初から閉じておくことが、攻撃の入口を減らす基本になります。
Permissions-Policy のセミコロンではなくカンマ区切りという点や、() で無効化する独特の書き方は、CSP と混同しやすいので注意してください。
なぜ併用が前提になるのか
ここまで読むと、2 つのヘッダがそれぞれ別の脅威に対応していることが分かります。だからこそ、どちらか一方では穴が残ります。
CSP だけを設定した場合、不正なスクリプトの実行は防げますが、埋め込みコンテンツが要求するカメラや位置情報の制御はできません。逆に Permissions-Policy だけを設定しても、ブラウザ機能は閉じられますが、XSS で読み込まれる不正スクリプトは止められません。
両者を併用して初めて、「読み込まれるコンテンツの安全」と「使われるブラウザ機能の安全」の両面をカバーできます。これが、セキュリティヘッダの解説で 2 つがいつもセットで登場する理由です。
2 つのヘッダを一緒に送るときは、別々の行として出力します。
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
このように、CSP はセミコロン区切りで読み込み元を、Permissions-Policy はカンマ区切りで機能の可否を、それぞれ独立して指定します。役割が分かれているので、設定が干渉することはありません。
自社サイトでの設定の進め方
最後に、Web 担当者が実際に手を動かすときの順序を整理します。
まず CSP は、いきなり厳しくすると正規のスクリプトまでブロックして表示が崩れることがあります。最初は違反を記録するだけのレポート専用モード（Content-Security-Policy-Report-Only）で様子を見て、問題がないことを確認してから本番のヘッダに切り替えるのが安全です。
Permissions-Policy は、まず「自社サイトが本当に使っている機能」を洗い出すところから始めます。カメラもマイクも位置情報も使っていないなら、それらを () で閉じても表示や動作に影響はありません。使わない機能を閉じることから着手すると、リスクなく守りを固められます。
ヘッダの配信場所はサイトの構成によって変わります。配信基盤として Cloudflare を使っているなら Cloudflare でのセキュリティヘッダ設定、WordPress で運用しているなら WordPress でのセキュリティヘッダ設定 を参照して、自社環境に合わせて設定してください。
設定後は、ヘッダが意図どおり送られているかを必ず確認しましょう。記述ミスや区切り文字の取り違えがあると、ヘッダが無効になっていることに気づけません。
よくある質問
CSP と Permissions-Policy は何が違いますか？
CSP はページが読み込むコンテンツ（スクリプトや読み込み元）を制御して XSS などを防ぎ、Permissions-Policy はカメラ・マイク・位置情報といったブラウザの強力な機能の利用可否を制御します。守る対象が異なります。
どちらか一方だけ設定すれば十分ですか？
不十分です。CSP だけでは埋め込みコンテンツが要求するカメラや位置情報の制御ができず、Permissions-Policy だけでは XSS で読み込まれる不正スクリプトを止められません。両者は併用が前提です。
CSP と Permissions-Policy で書き方はどう違いますか？
CSP はディレクティブをセミコロン（;）区切りで並べ、Permissions-Policy は機能名と許可リストをカンマ（,）区切りで並べます。Permissions-Policy は () で機能を無効化する独特の書き方を使う点も異なります。
まとめ
CSP と Permissions-Policy は、名前は似ていても守る対象がまったく違います。CSP は読み込むコンテンツとスクリプト実行を制御して XSS やクリックジャッキングを防ぎ、Permissions-Policy はカメラ・マイク・位置情報などのブラウザ機能の利用可否を制御してプライバシーと端末を守ります。両者は競合ではなく併用が前提であり、2 つそろって初めてサイトの守りが立体的になります。
自社サイトのセキュリティヘッダが正しく設定されているか不安な方は、無料診断 で現状をチェックできます。CSP や Permissions-Policy を含むヘッダの状態を可視化し、Web 担当者が次に何をすべきかをはっきりさせるところから始めましょう。