Defaults.Exposed › 修正 › Referrer-Policy
Referrer-Policy の直し方
Referrer-Policyは、ウェブサイトがすべての訪問者のブラウザに渡す1行の指示で、別のサイトへリンクをクリックしたときにあなたのウェブアドレスのどれだけが一緒に持ち出されるかを制御します。これがないと、訪問者が見ていたページの完全なアドレス—検索語・口座番号・再設定リンク・内部のページパスまですべて—が、次に着地したサイト(広告主・分析会社、リンク先がどこであれ)に静かに手渡されます。
あなたのビジネスにとっての結論: 訪問者が外部リンク・広告・共有リソースをクリックするたびに、ブラウザはあなたのページの完全なアドレスをリンク先に渡せます。アドレスに検索クエリ・顧客ID・注文番号・ワンタイムリンクが含まれていれば、制御できない第三者に顧客データを漏らしていることになります。これは規制当局が真剣に受け止めるデータ保護の問題であり、静かに破られたプライバシーの約束であり、デューデリジェンスで顧客のセキュリティチームが指摘する評点付きのギャップです。
これで失いかねないもの
- 顧客がフォームに記入するか検索を実行し、それから外部リンクや広告をクリックします—すると入力した内容を含むページアドレスが、共有するつもりのなかった広告主や分析会社にまっすぐ手渡されます。
- パスワード再設定やアカウント確認のリンクは、ウェブアドレスに秘密のトークンを含むことがあります。このヘッダーがないと、そのページのリンクをクリックするだけで、トークンを含む完全なアドレス全体が外部サイトに渡りえます。
- プライベートな内部ページパス(管理領域、顧客専用ページ、料金プラン、書類リンク)が、訪問者がクリックして移る第三者すべてに露わになり、見るべきでないサイトの地図を競合や詮索者に渡します。
- 顧客のセキュリティ審査やプライバシー監査がサイトをスキャンし、Referrer-Policyがないのを見て、データ最小化の不備として記録します—契約や認証を止める類の指摘です。
- 個人データが、契約のない処理者の手に渡り、5分の見落としが報告対象のデータ保護違反に変わります。
なぜ重要か。 ブラウザは放っておくとおしゃべりです。初期状態では、訪問者がどこから来たかを次のウェブサイトに伝え、しばしばページの完全なアドレスを含みます。案内だけのサイトならそれは無害かもしれませんが、アドレスに個人的なもの—検索語・注文ID・リンク内のメール・プライベートなパス—が含まれた瞬間、その初期設定はそれを外部に静かに漏らします。Referrer-Policyは、ブラウザに共有しすぎをやめさせる単一の設定です。スコアカード上の相応の点に値する評点付き検査で、プライバシー法のデータ最小化義務に直結し、プロの審査が見つけることを期待する標準的なセキュリティヘッダーのひとつです。
これは何か、平易に言うと
あなたのウェブサイトの訪問者が別のサイトへリンクをクリックするたび—外部リンク、バナー広告、『これを共有』、よそから読み込まれるフォントや画像でさえ—ブラウザはあなたのどのページから来たかを示す覚書を静かに添えます。その覚書がreferrerです。
賢く使えば、referrerは無害でむしろ役立ちます。他のサイトがあなたから来た流入を知る手段で、多くの正直な分析を支えます。落とし穴は初期の挙動にあります。管理されないままだと、ブラウザは『your-business.comから来た』だけでなく、しばしばドメイン名の後ろのすべてを含む正確なページの完全アドレスを渡します。そしてウェブアドレスは人が思う以上のものを運びます。サイトに入力された検索語、注文・アカウント番号、会員専用ページへのパス、パスワード再設定や確認リンクのワンタイム秘密トークンまで。
Referrer-Policyは、ウェブサイトがブラウザに送る単一の指示で、その覚書をどれだけ共有してよいかを告げます。ドメイン名だけ共有する、自分のサイトの他のページにだけ共有する、まったく何も共有しない、と指示できます。見知らぬ者に毎日の予定付きで完全な自宅住所を渡すか、住んでいる町だけを告げるか、の違いと考えてください。
これは、サイトがすべての訪問者のブラウザに与える短い指示『セキュリティヘッダー』の小さな一族のひとつです。サイトの見た目や動作を変えません。ただ、ブラウザがあなたに代わって共有しすぎるのを止めるだけです。
これが招きうる損失
欠けている・寛容なReferrer-Policyが実在のビジネスを噛む、具体的で日常的な形です。どれもハッカーを必要とせず—通常の使用の中で、毎日、自動で起きます。
-
漏れた検索。 顧客が機密的なもの—医療製品、債務関連サービス、競合比較—をサイトで検索し、検索語がページアドレスに入ります。それから結果ページの外部リンクや広告をクリックします。広告主は今や検索語の入ったあなたのアドレスを受け取り、顧客が何を探していたか正確に知ります。あなたは共有に同意しておらず、取り戻すこともできません。
-
露出した再設定リンク。 多くのシステムは、パスワード再設定・メール確認・『マジックログイン』ページのアドレスに秘密のワンタイムトークンを入れます。そのページに外部リンクや第三者リソースがあれば、トークンを含む完全アドレスが外部サイトに渡りえます。最悪の場合、アカウントの鍵を第三者に渡します。
-
無料で渡したサイト地図。 内部のページパスはしばしば構造を露わにします。/admin、/enterprise-pricing、/clients/acme、/downloads/private-report。このヘッダーがないと、訪問者がクリックして移る外部サイトすべてがそれらのパスを受け取ります。競合は料金プランや製品ラインを学び、スクレイパーは狙うべきページを学びます。
-
望まないデータ共有関係。 プライバシー法は、顧客の個人データの行き先を把握し契約を結ぶことを期待します。顧客IDやメールアドレスを含むページアドレスを、契約も同意もなく広告ネットワークや分析会社に漏らすことは、まさに定例監査を指摘事項に、指摘事項を報告対象の違反に変える、制御されないデータフローです。
-
デューデリジェンスで止まる商談。 大口顧客のセキュリティチームがあなたを審査するとき、欠けている標準的なセキュリティヘッダーは手早い自動のチェック項目です。Referrer-Policyがないのを見れば、基本的なプライバシー衛生が一度も整っていなかったと伝わり、その印象が審査の他のすべてに影を落とします。
これの実体
初期状態でブラウザは、最新版ではおおむね『strict-origin-when-cross-origin』に相当する挙動に従いますが、それに頼ることはできません。古いブラウザ・組み込みのwebview・特定の設定は、依然としてより多くを漏らすほうにフォールバックするからです。確実にする唯一の方法は、ポリシーを明示的に設定することです。設定するとき、短いリストからひとつのルールを選びます。重要なもの:
- no-referrer — 何も共有しない。次のサイトは訪問者がどこから来たか何も告げられません。最大のプライバシー。参照元分析を弱めることがあります。
- same-origin — 訪問者が自分のサイトのページ間を移るときだけ完全アドレスを共有し、外部サイトには何も共有しません。
- strict-origin-when-cross-origin — 推奨の既定。自分のサイト内では完全パスを共有し、外部サイトには裸のドメイン名だけ(安全なページから安全でないページへ移るときは何も)共有します。外部は流入があなたから来たと学びますが、ドメインの後ろのプライベートな詳細は決して学びません。
- origin — 自分のサイト内でも常にドメイン名だけを共有します。
そして避けるべき2つの値。スコアカードはこれらをヘッダーがないのと同等に扱います:
- unsafe-url — 完全アドレスを常に全員と共有。一言で言う最悪の場合。
- no-referrer-when-downgrade — 古いブラウザの既定。他の安全なサイトには依然として完全アドレスを送り、上記のすべてを漏らします。
『良い』状態とは: Referrer-Policyヘッダーが存在し、制限的な値に設定されていること—ほとんどの企業にはstrict-origin-when-cross-origin。これは参照元分析を機能させたまま、ドメイン名より先のものが決して外部サイトに届かないようにします。
修正方法(無料・約5分)
IT担当・ウェブ開発者・ホスティングのサポートにこの項を渡してください。修正は無料で、1行で、サイトを壊しません。 ここには危険な展開はありません。一部のセキュリティ設定と違い、まともなReferrer-Policyはリンクやページの機能を止めることはできません。他のサイトと共有されるものを絞るだけです。
目標:Referrer-Policyレスポンスヘッダーを値strict-origin-when-cross-origin(さらに共有を減らしたければより厳しい値)で設定すること。
Cloudflare(コードなし—使っているなら最も簡単):
Dashboard → ドメイン → Rules → Transform Rules → Modify Response Header → Create rule → Set static → ヘッダー名Referrer-Policy、値strict-origin-when-cross-origin → すべての受信リクエストに適用 → Deploy。
Google Workspace / Microsoft 365: これらはメールを管理するもので、ウェブサイトではないので、ヘッダーはサイトが実際にホストされている場所(ウェブホスト、CDN、サーバー)で設定し、Workspaceや365の管理画面では設定しません。ホストを特定し、下の該当するオプションを使ってください。
Nginx:
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
Apache(サイト設定か.htaccessに):
Header always set Referrer-Policy "strict-origin-when-cross-origin"
IIS(web.config):
<httpProtocol><customHeaders>
<add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>
Node / Express:
app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });
WordPress / 一般的なホスト: ほとんどのマネージドWordPressや共用ホストは、セキュリティプラグイン、ホスティングのコントロールパネルの『headers』パネル、または上の.htaccessスニペットでレスポンスヘッダーを追加できます。Cloudflareの背後にいるなら、Cloudflareの方法が最もきれいで一度にどこにでも適用されます。
適用後: サイトを読み込んで検査を再実行するか、ブラウザの開発者ツール(Networkタブ → メインのドキュメントをクリック → Response Headers)でReferrer-Policy: strict-origin-when-cross-originがあることを確認します。
よくある間違い
- 寛容な値を設定し、それで数えられると思い込む。
unsafe-urlとno-referrer-when-downgradeはどちらも依然として完全アドレスを漏らします。スコアカードはそれらを0点—ヘッダーがないのと同じ—に採点します。ヘッダーはあるのに点がない場合、ほぼ常にこれが理由です。 - ホームページだけに設定する。 ヘッダーはすべてのページに送るべきです。漏れは検索結果・アカウント・再設定のページで起きるからで、ホームページではありません。サーバー・CDN・Cloudflareのレベルで設定し、サイト全体に自動適用します。
- HTMLの
<meta>タグだけに設定する。<meta name="referrer">タグは一部の場合には効きますがすべてではなく、ページ間で一貫させにくいです。適切なレスポンスヘッダーとして設定する(上の方法)のが確実です。 - ある層が別の層を上書きするのを許す。 オリジンサーバーとCDNの両方が異なる値でヘッダーを設定すると、結果が予測不能になりえます。管理する場所をひとつ選び—CDNやCloudflareがあれば通常それ—残りを一貫させましょう。
- URLからデータを排除する代わりとして扱う。 ヘッダーは被害を抑えますが、より良い長期の習慣は、そもそもウェブアドレスに秘密や個人データを入れないことです。今はヘッダーを使い、URLの衛生は後続として開発者に提起しましょう。
関連ヘッダーについての一言
Referrer-Policyは、当社が検査する他のいくつかのウェブセキュリティヘッダー—Content-Security-Policy、X-Frame-Options、X-Content-Type-Options、いくつかの高度なクロスオリジンヘッダー—と並びます。守るものが違うので、ひとつあっても他をカバーしません。Referrer-Policyが欠けているなら、それを直す人に、同時に他の標準ヘッダーも整っているか確認してもらう価値があります。たいてい同じひとつの場所で設定でき、追加の手間はかからないからです。
要するに
Referrer-Policyはスコアカード上で最も安く安全なプライバシー修正です。1行、約5分、何も壊すリスクなし、無料。訪問者のブラウザが、あなたのプライベートなページアドレス—とそこに含まれる個人データ—を、クリックして移る外部サイトすべてに静かに手渡すのを止めます。strict-origin-when-cross-originに設定し、すべてのページで有効か確認すれば、中重大度のギャップとその15点が閉じます。
よくある質問
技術に詳しくありません。本当に自分で対応できますか?
はい、スコアカード全体で最も簡単な修正のひとつです。ウェブサイトやホスティングを運用している人が追加する1行で、Cloudflareのようなサービスではコードなしの数クリックです。下の『修正方法』の項を渡してください。無料で、約5分、一部のセキュリティ設定と違ってサイトの何も壊しません。
ここでの『referrer』とは何を意味しますか?
誰かがあなたのページから別のウェブサイトへリンクをクリックすると、ブラウザはどのページから来たかを示す覚書を一緒に送ります—その覚書がreferrerです。正直な分析には本当に役立ちます。問題は、初期状態でその覚書がドメイン名だけでなく完全なページアドレスを含むことが多いことです。そのアドレスにプライベートなものが含まれていれば、それも共有されます。Referrer-Policyを使えば、覚書をドメインだけに絞るか、オフにして、機密が漏れないようにできます。
決済を扱わないサイトでも、わざわざやる価値はありますか?
ほぼ確実にあります。ウェブアドレスにプライベートな情報が入るのに決済は要りません—検索ボックス・問い合わせフォーム・アカウントページ・書類リンク・パスワード再設定メールは、どれも日常的にアドレスバーにデータを入れます。そして個人データがまったくなくても、内部のページパスを訪問者がクリックする外部サイトすべてに漏らすことは、競合やスクレイパーにサイトの地図を無料で渡します。修正は費用ゼロで5分なので、飛ばす理由はほとんどありません。
これをオンにするとサイトや分析が壊れますか?
いいえ。これは安全なヘッダーのひとつで、他のサイトとどれだけアドレスの詳細を共有するかだけを制御し、リンクが機能するかどうかは制御しません。推奨設定は外部サイトにドメイン名は送るので、正規の参照元分析は機能し続けます。完全なプライベートアドレスが一緒に行かなくなるだけです。監視のみの試行は不要で、ステージングで先にテストするものもありません。
これはプライバシー法の問題ですか、それとも単なるあると良いものですか?
正真正銘のコンプライアンス問題になりえます。データ保護規則は、必要最小限の個人データだけを収集・共有し、データの行き先を把握することを求めます。アドレスに個人識別子が含まれ、それを契約のない広告主や分析会社に漏らせば、監査人や規制当局が認識するデータ最小化の不備です。ほとんどの企業にとって、このヘッダーはそのギャップを閉じる安価で具体的な手段です。
これは評点に影響しますか、それとも助言だけですか?
評点に影響します。Referrer-Policyの検査は評点付きで、ウェブセキュリティのカテゴリーで最大15点に値します。欠けているヘッダーは中重大度と表示されます。ひとつの罠に注意:ヘッダーを'unsafe-url'や'no-referrer-when-downgrade'のような寛容な値に設定すると0点—ヘッダーがないのと同じ—になります。それらの値は依然として完全なアドレスを漏らすからです。点を得るには'strict-origin-when-cross-origin'のような適切に制限的な値が必要です。