HTTP レイヤーでのデフォルト・プライバシー：トラッキング面を縮小するヘッダー

ほとんどのプライバシー対策は JavaScript の中で行われる——同意ロジック、タグのゲーティング、識別子のローテーションなどだ。しかしブラウザは、スクリプトが 1 つも実行される前に監視面を閉じる 2 つの HTTP レスポンスヘッダー を提供しており、ほとんどのサイトはそのどちらも送っていない。Permissions-Policy と Referrer-Policy は、最も文字通りの意味でのプライバシー・バイ・デザインである。つまりコードではなく設定だ。

これらは 1 年前よりも今のほうが重要になっている。Google が 2025 年 10 月に大半の Privacy Sandbox API を廃止したことで、それらの API が導入した残存する広告テック向けディレクティブは依然として Chrome に組み込まれたままだ——そして今、サイトはそれらが削除されるのを待つのではなく、能動的にオフにできるようになった。

Permissions-Policy：使わない機能を拒否する

Permissions-Policy は、ドキュメントとその埋め込みフレームがどのブラウザ機能を使えるかを制御する。これは camera、geolocation、microphone をゲートするのと同じ仕組みだが、広告テックが手を伸ばすトラッキング関連の API もゲートする。

これらの多くについて、デフォルトの許可リストは寛容だ。Topics API を制御するディレクティブである browsing-topics はデフォルトで * になっており——あなたが明示的に指定しない限り、第三者フレームを含むページ上のすべてのオリジンがそれを呼び出せる。無効化はわずか 1 行だ。

Permissions-Policy: browsing-topics=()

空の許可リスト () は、自分自身のオリジンを含めすべての相手に対してその機能を拒否する。広告関心と計測用の API 群一式を、単一のヘッダーでまとめてロックダウンできる。

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()

ファーストパーティか埋め込みかを問わず、document.browsingTopics() を呼び出したり Sec-Browsing-Topics リクエストヘッダーを送ったりするスクリプトは、これで NotAllowedError で失敗するようになる。あなたは第三者が行儀よく振る舞うことを信頼しているのではない。プラットフォームのレベルでその能力そのものを取り除いているのだ。

これらのディレクティブは Privacy Sandbox とともに非推奨になっているため、いくつかは今後の Chrome のリリースで消えていく。() に設定しておけば、それらが消えた後は無害であり、消えるまでは保護として働く。

Referrer-Policy：URL の漏洩を止める

すべてのナビゲーションとサブリソースのリクエストは、ユーザーがどのページから来たかを示す Referer ヘッダーを運ぶ可能性がある。完全な URL は、クエリ文字列、パスにエンコードされた識別子、検索語、内部のページ構造を、あなたが読み込むすべての第三者——アナリティクスベンダー、フォント、CDN、広告ピクセル——に漏らす。

現代のブラウザはデフォルトで strict-origin-when-cross-origin を採用しており、これはすでに妥当な下限だ。

Referrer-Policy: strict-origin-when-cross-origin

このポリシーの下では、ブラウザは 同一オリジン のリクエストでのみ完全な URL を送り、クロスオリジンのセキュアなリクエストでは オリジンのみ を送り、HTTPS から HTTP へのダウングレード時には 何も 送らない。つまり https://app.example/orders/4815?token=abc は、第三者には https://app.example/ として届く——オリジンのみで、パスもクエリもない。

このデフォルトは 2020 年 11 月に仕様上のデフォルトになったが、それでもヘッダーは明示的に設定すべきだ。設定を誤った上流、古いフレームワークのデフォルト、あるいは <meta> referrer タグがこれを上書きしうるし、明示的なヘッダーは監査可能だ。URL に機密情報を一切埋め込まず、より厳格にしたいなら、strict-origin は同一オリジンのリクエストでもパスを落とす。

なぜこれが Cookie なしのアナリティクスと相性が良いのか

これらのヘッダーとプライバシー優先のトラッカーは、同じ問題を 2 つの方向から解決する。トラッカーは あなたの アナリティクスが何を収集するかを制御し、ヘッダーはページ上の 他のすべての人 が何に手を届かせられるかを制御する。

一方向の日次ハッシュ——SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)——から識別子を導出する Cookie なしのトラッカーは、その仕事をするために完全な referrer URL も Topics API も必要としない。訪問元を帰属させるためだけに document.referrer を読むのであり、それにはオリジンで十分だ。したがって Referrer-Policy を厳しくしても、あなたのアナリティクスには何のコストもかからず、その一方でページ上の他のすべてのリクエストの漏洩口を塞ぐ。

同じ整合性はパフォーマンスにも当てはまる。ヘッダーは JavaScript を 0 バイトも消費せず、メインスレッドの時間も 0 だ。パースの前にブラウザによって評価される。Largest Contentful Paint や Interaction to Next Paint に何の影響も与えずに、測定可能なプライバシー改善が得られる——これは同意管理プラットフォームとは正反対のトレードオフだ。同意管理プラットフォームは、ヘッダーなら端的に拒否できたはずの権限を管理するためにスクリプトの重みを追加してしまう。

エッジでデプロイする

両方のヘッダーをエッジまたはオリジンサーバーで設定し、静的アセットや HTML を含むすべてのレスポンスがそれらを運ぶようにしよう。

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin

Cloudflare では Transform Rule か Worker で追加する。Next.js では headers() の設定で。任意のリバースプロキシでは、1 行の add_header で済む。ロールアウトのリスクはない。あなたは使っていない能力を拒否し、そもそも送りたくなかったデータを切り詰めているだけだ。

プライバシー・バイ・デザインは通常、アーキテクチャ上の決定として語られる。HTTP レイヤーでは、それは 2 行の設定であり、それらはあなたが閉じるまでデフォルトで開いている。

ソース

• Permissions-Policy ヘッダー（MDN Web Docs）
• Permissions-Policy：browsing-topics ディレクティブ（MDN Web Docs）
• Referrer-Policy ヘッダー（MDN Web Docs）
• Permissions Policy でブラウザ機能を制御する（Chrome for Developers）
• Privacy Sandbox 技術の計画に関するアップデート（Google）