リファラー（Referer / Referrer）とは？仕組み・リファラー制御と「リファラを有効にしてください」の対処

リファラーは、ブラウザがリンク元のURLをリクエストに添えて送るHTTPヘッダーです。APIキーの「HTTPリファラー制限」や予約サイトに出る「リファラを有効にしてください」はこのヘッダーを見ており、アクセス解析の参照元は同じ情報をJavaScriptで読めるdocument.referrerなどから判定します（GA4ではpage_referrerの既定値）。2020年のChrome 85、2021年のFirefox 87と主要ブラウザの既定が順に変わり、ポリシーを指定していないページから別サイトへはパスもクエリも届かなくなりました。この記事では、送信条件とReferrer-Policyによるリファラー制御、エラー表示の原因と対処、確認方法を、仕様の原文とnginx・Djangoでの実測で整理します。

まとめ：リファラー制御で押さえる6点

• ヘッダー名はReferer（中央のrを重ねない綴り）。RFC 9110は綴り誤りを示す[sic]を付けたまま、この名前で定義しています。
• 既定のポリシーはstrict-origin-when-cross-origin。別オリジンへはオリジンのみ、HTTPSからHTTPへは何も送られません。
• 「リファラを有効にしてください」は、サイト側がRefererの有無で直接アクセスを弾いているときに出ます。ブックマークやホーム画面から途中の画面を開いたことが原因の場合があります。まず入口のページから操作し直してください。
• Chrome・Safari・Edgeには、リファラー送信をオフにする設定項目がありません。送信されない原因には、リンク元のポリシー、遷移方法、拡張機能やセキュリティソフトなどがあります。Firefoxではabout:configの変更も確認対象です。
• 制御手段はReferrer-Policyヘッダー、meta要素、referrerpolicy属性、rel="noreferrer"の4つ。ただしSafariはITPが有効な場合、Firefoxは既定設定の画像などのサブリソース要求とプライベートウィンドウで、サイトが緩いポリシーを指定してもクロスサイトではオリジンまで切り詰めます。
• RefererはJavaScriptから任意の値に書き換えられない一方（fetch()のreferrerで選べるのは同一オリジンのURLか空文字列まで）、curlなどからは自由に詐称できます。認証の代わりには使えません。

リファラー（Referer）の定義と綴り

RFC 9110が残した綴り誤り

HTTPの現行仕様RFC 9110 §10.1.3（2022年6月）は、このヘッダーをThe "Referer" [sic] header fieldと書き、括弧で「though the field name is misspelled」と添えたうえで綴りをそのままにしています。HTTP/1.0のRFC 1945（1996年5月）§10.13の時点ですでにRefererでした。

その結果、同じ概念の名前が2通り併存しています。リクエストヘッダーはReferer、後から加わったレスポンスヘッダーReferrer-PolicyとJavaScriptのdocument.referrerは正しい綴りです。設定で綴りを間違えるとエラーにならず無視されるだけなので、どちら側の名前かを確かめてから書いてください。

リファラー・リファラ・リファラルの違い

「リファラー」と「リファラ」は表記ゆれで、指すものは同じです。「リファラル（referral）」は紹介・推薦を意味する別語で、GA4のメディアreferralは参照元サイトからの流入を指しますが、リファラル採用やリファラルマーケティングとは無関係です。

リファラーが送られる条件と届く範囲

リファラーの送信条件と非送信条件

リファラーが付くのは、あるページを起点に次のリクエストが発生したときです。リンクのクリック、画像やスクリプトの取得、iframeの読み込み、フォーム送信が該当します。次の場合はヘッダーそのものが付きません。

• URLの直接入力、ブックマーク、ホーム画面に追加したアイコンなど、参照元ページを伴わない新規アクセス
• メールソフトやネイティブアプリ内のリンク、QRコードの読み取り（Webページが起点でない）
• HTTPSのページからHTTPのページへの遷移（既定ポリシーが遮断）
• リンク元がrel="noreferrer"やReferrer-Policy: no-referrerを指定している場合
• 拡張機能やセキュリティソフトがヘッダーを削除している場合

リファラー送信時のフラグメント・認証情報の除去

Referrer Policy仕様の「Strip url for use as a referrer」は、送信前にURLのfragment・username・passwordを必ず取り除くと定めています。RFC 9110 §10.1.3もfragmentとuserinfoを含めてはならない（MUST NOT）と書いています。https://example.com/page#sectionから遷移しても、受け取り側に#sectionは届きません。

Firefoxには長さの上限もあり、network.http.referer.referrerLengthLimitの既定は4096です。超えたURLはオリジンまで切り詰められ、コンソールにReferrerLengthOverLimitationが出ます。オリジンだけでも超える場合はリファラー自体が空になります。

「リファラを有効にしてください」と表示されたときの原因と対処

サイト側のRefererチェックとエラー表示

このメッセージはブラウザのエラーではなく、閲覧先のサイトが出しています。予約・申込・決済のように画面が順番に進むサービスは、途中の画面へ外から直接入られないよう、Refererに自サイトのURLが入っているかを確かめることがあります。Refererが無ければ「正しい順路で来ていない」と判断して、この案内を出します。

典型例がGoogle Pixelコミュニティへの質問です。免許更新の予約で、予約確定の画面をホーム画面に保存して開いたところ、「リファラを有効にしてください」と表示されて目的の画面が出なかったという内容です。ホーム画面のアイコンから開くとRefererは付かないため、サイト側のRefererチェックに当たった可能性が高い事例です（サイトの判定条件そのものは公開されていません）。

利用者側で確認する順序

1. サービスのトップページか、案内メールに書かれた入口のURLから開き直し、画面内のボタンで目的の画面まで進む。途中の画面への直接アクセスによるRefererの欠落が原因なら、入口から操作し直すことで解消する可能性があります。
2. シークレットウィンドウ（プライベートブラウズ）で同じ手順を試す。拡張機能に加えてCookieやログイン状態も通常ウィンドウと異なるため、通っただけでは原因を確定できません。通常ウィンドウで拡張機能を個別に無効化して再確認します。
3. 拡張機能を1つずつ無効にする。Referer Controlのような書き換え目的の拡張に加え、広告ブロック・プライバシー保護系の拡張もヘッダーを削除できます。Chromeの拡張APIはdeclarativeNetRequestでrefererをremoveするルールを書けるためです。
4. セキュリティソフトの公式手順で、Web保護・プライバシー保護機能が通信に影響していないか確認する。通信を中継してヘッダーを落とす製品があるためです。一時停止が必要な場合は対象サイトでの確認に限り、確認後すぐに元へ戻します。
5. Firefoxの場合だけ、次項のabout:configの値を確認する。

以上で解決しない場合は、リンク元のページがno-referrerを指定している、HTTPのページへ遷移している、といったサイト側の事情も考えられます。表示された画面と操作手順を添えて、サービスの問い合わせ窓口に伝えてください。

Chrome・Safari・スマホの送信設定の有無

ブラウザの設定画面を探しても、chrome://settings・edge://settings・Safariの設定のいずれにもリファラー送信を切り替える項目は見当たりません。iPhoneやAndroidのブラウザも同じで、どれも既定で送信しています。スマホで表示されたときも、まず手順1の「入口から開き直す」を試してください。

Firefoxでリファラーを有効に戻す手順

Firefoxだけはabout:configで送信を止められるため、過去に変えた値が残っていることがあります。アドレスバーにabout:configと入力し、network.http.sendRefererHeaderを検索してください。0または1なら既定の2へ戻します。network.http.referer.XOriginPolicyとnetwork.http.referer.trimmingPolicyが0以外なら、どちらも0へ戻します。各値の意味は後述の表のとおりです。

運営側：Refererが無いだけで弾かない設定

サイトを運営する側から見ると、Refererの無いアクセスを一律に拒否すると、ブックマークやホーム画面から来た正規の利用者まで止めてしまいます。nginxのドキュメントも「regular browsers may not send the “Referer” field even for valid requests」と注意しています。nginx 1.29.8の公式Dockerイメージに次の設定を入れ、Host: example.comを付けたcurlでRefererだけを変えて送った結果が下の表です。

server {
    listen 80;
    server_name example.com;
    location /strict/ {
        valid_referers server_names;
        if ($invalid_referer) { return 403; }
        return 200 "ok\n";
    }
    location /lenient/ {
        valid_referers none blocked server_names;
        if ($invalid_referer) { return 403; }
        return 200 "ok\n";
    }
}

noneはRefererが無い場合、blockedはファイアウォールやプロキシに値を消された場合を許可する指定です。直リンク対策のように「他サイトからの参照だけ止めたい」なら、none blockedを付けた右列の書き方にすれば、ブックマーク経由の利用者を巻き込みません。

フレームワークのCSRF対策も同じ表示の出どころになります。DjangoのCsrfViewMiddlewareは、HTTPSで受けたPOST・PUT・DELETEなど安全でないメソッドのリクエストにOriginヘッダーが無い場合、Refererを検査します（Django公式ドキュメント）。Django 6.1.2のテストクライアントで、CSRFトークンとCookieを正しく付け、CSRF_TRUSTED_ORIGINSは空のままPOSTを送り比べた結果は次のとおりです。

Refererが無いときの403画面には、Refererを「please re-enable them, at least for this site」と再有効化を求める英文が出ます。各社の「リファラを有効にしてください」と同じ趣旨の案内です。最後の行は、サイト自身がno-referrerを指定した場合です。Fetch仕様では、ポリシーがno-referrerのときPOSTのOriginはnullになるため、今度はOriginの照合で落ちます。Djangoで自サイトにno-referrerを全体指定すると、フォームが通らなくなります。

Referrer-Policyの8つの値と既定値

既定ポリシーstrict-origin-when-cross-originの送信範囲

Referrer Policyの現行仕様は§3で、既定のポリシーをstrict-origin-when-cross-originと定めています。何も指定していないサイトにはこの値が適用されます。

古い解説と食い違うのはここです。W3CのTR版ページ（2017年1月26日のCandidate Recommendation）は既定をno-referrer-when-downgradeと記載したまま公開されており、これを参照した記事が旧既定を書き続けています。実装が先で、Chromeはバージョン85で既定を切り替え、仕様の既定が改まったのは2020年11月です。旧既定に戻す管理者ポリシーForceLegacyDefaultReferrerPolicyはChrome 80〜87だけの対応で、88で削除されました。

具体的には、https://site-one.example/stuff/detail?tag=redから別オリジンへ遷移すると、旧既定ではURL全体が届いていたのに対し、現在はhttps://site-one.example/だけになります。

8つの値とオリジン別の送信内容

「完全URL」はオリジン・パス・クエリ文字列を含みます。unsafe-urlはHTTPSのURLを平文通信に漏らすため、仕様自身が警告を付けています。既定より漏らさない方向に寄せるならsame-origin・strict-origin・no-referrerから選んでください。

リファラー制御の設定方法：ヘッダー・HTML・ブラウザ

Referrer-Policyヘッダー（nginx・Apache）

サイト全体に効かせる標準の手段です。nginxでは次のように書きます。

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

末尾のalwaysは省略しないでください。nginxのadd_headerは、alwaysが無いと200・201・204・206・301・302・303・304・307・308の応答にしかヘッダーを付けず、404や500では消えます。もう1つの落とし穴が継承で、現在のレベルにadd_headerが1つでもあると上位レベルの指定を引き継ぎません。特定のlocationだけポリシーが効かないときは、そのlocationに別のadd_headerが無いかを確認してください。1.29.3以降はadd_header_inherit merge;で継承させられます。

Apacheはmod_headersを有効にして次の1行を足します。ここでもalwaysを省くと、ErrorDocumentで返す応答にヘッダーが付きません。

Header always set Referrer-Policy "same-origin"

ヘッダーにはカンマ区切りで複数の値を並べられ、ブラウザは解釈できる最後の値を採用します。この複数値指定はヘッダーでだけ有効で、referrerpolicy属性では使えません。

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

Content-Security-PolicyやHSTSと並ぶセキュリティヘッダーの1つとして、まとめて設定する場面が多い項目です。CSPの書き方はコンテンツセキュリティポリシー（CSP）とは？nonce方式の設定とXSS防御の実装判断を解説で扱っています。

meta要素・referrerpolicy属性・noreferrerの使い分け

サーバー設定を触れない場合は、HTMLで3段階の粒度を選べます。文書全体ならmeta要素です。

<meta name="referrer" content="origin">

リクエスト単位ならreferrerpolicy属性を使います。a・area・img・iframe・script・link要素に書けます。

<a href="https://example.com/" referrerpolicy="origin">製品ページ</a>
<img src="https://cdn.example.net/logo.png" referrerpolicy="no-referrer" alt="ロゴ">

特定のリンクだけ完全に遮断するならrel="noreferrer"です。relの値はハイフンなしのnoreferrer、ポリシー名はハイフンありのno-referrerで、取り違えると効きません。同じrelに並べることが多いnoopener・nofollowとの違いは、nofollowとは？noindex・noopenerとの違いと正しい書き方で整理しています。

完全URLを受け取りたい場合の限界

「2020年以降、流入元のパスが取れなくなった」への対処として、リンク元のページにno-referrer-when-downgradeやunsafe-urlを指定する方法が紹介されています。Chromeでは有効で、公式ブログも「you can still set a policy of your choice」と書いています。ただしリンク元のポリシーはリンク元のサイトでしか変えられず、受け取る側だけでは対処できません。また指定しても、ブラウザによっては切り詰められます。

• Safari：WebKitのトラッキング防止は「All third-party referrers are downgraded to their origins by default」で、HTTPヘッダーとdocument.referrerの両方が対象です。全クロスサイト要求への適用はmacOS版Safari 13.0.4、iOS 13.3から。WebKitの開発者はバグ報告218909で、サイトのポリシーに関係なく切り詰める（regardless of any site policy）のが意図した動作だと書いています。
• Firefox：network.http.referer.disallowCrossSiteRelaxingDefaultが既定でtrueで、画像やスクリプトなどのクロスサイト要求ではunsafe-url・no-referrer-when-downgrade・origin-when-cross-originを無視します。リンクのクリックのようなトップレベル遷移は、通常ウィンドウでは別設定（.top_navigation）が既定でfalseのため指定どおり送られ、プライベートウィンドウではtrueのため切り詰められます。
• Brave：2021年以降、Desktop版とAndroid版で既定をstrict-origin-when-cross-originにしており、Shieldsのソースにはそれより緩いポリシーをこの値に抑える処理があります。

キャンペーン単位の流入を区別したい場合は、リンクにUTMパラメータを付けます。参照元のパスも区別したい場合は、識別値を設計し、遷移先でパラメータが保持・計測されることを確認してください。

ブラウザ側の既定を変える設定値（Firefox）

Firefoxではabout:configから送信条件を設定でき、Geckoのソース（StaticPrefList.yaml）にある既定値と取り得る値は次のとおりです。

network.http.referer.defaultPolicyの値は、0がno-referrer、1がsame-origin、2がstrict-origin-when-cross-origin、3がno-referrer-when-downgradeに対応します。

リファラーを確認する方法：DevTools・curl・GA4

開発者ツールのNetworkタブ

Chrome DevToolsなら「Network」タブで対象のリクエストを選び、「Headers」の「Request Headers」を見ます。Firefoxは「ネットワーク」タブの「メッセージヘッダー」です。Refererの行があればその値が送られた内容で、行そのものが無ければ送られていません。ただし「Provisional headers are shown」と表示されているときはキャッシュなどによる暫定表示なので、キャッシュを無効にして再取得してから判断してください。

JavaScriptからはdocument.referrerで読めます。値が入るのはナビゲーションとiframeの場合だけで、画像やスクリプトの取得に付いたリファラーはここから読めません。

curlの-eオプションによるリファラー指定

サーバー側のリファラーチェックを試すなら、curlの-eオプションで値を指定します。

curl -s -e "https://example.com/page?q=123" https://httpbin.org/headers

curl 8.7.1での結果は次のとおりで、指定した値がそのままRefererとして届いています（リクエストごとに変わるX-Amzn-Trace-Idの行は省略）。

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "Referer": "https://example.com/page?q=123",
    "User-Agent": "curl/8.7.1"
  }
}

-eを外すとRefererの行自体が消えます。前章のnginxの表も、この方法でRefererを付け替えて測ったものです。

JavaScriptのヘッダー指定制限とreferrerオプション

ブラウザ内のJavaScriptからは、Refererヘッダーを直接指定できません。Fetch仕様のforbidden request-headerにRefererが含まれ、CookieやHostと同じ扱いで、fetch()やXMLHttpRequestのヘッダーに書いても無視されます。用意されているのはfetch()のreferrerオプションで、同一オリジンのURLか空文字列（送らない）を指定でき、別オリジンのURLを渡すと通常の値に戻されます。値を決めるのがブラウザだけである範囲では検証に意味がありますが、その保証はブラウザ経由のリクエストにしか及びません。境界の考え方は同一オリジンとは？判定条件とSame-Origin Policyが止めるもの・止めないものと同じです。

GA4のpageReferrerによる参照URLの確認

GA4で参照元のURLそのものを見るなら、ディメンション「Page referrer」（API名pageReferrer）を使います。GA4 Data APIのスキーマは「The full referring URL including the hostname and path」と説明し、値はイベントパラメータpage_referrerから入ると書いています。ただし中身はブラウザが渡したリファラーなので、相手サイトが既定ポリシーのままなら外部からの流入はオリジンまでしか入りません。既定ポリシーでは、同一オリジン内の遷移ならパスも含まれます。外部サイトからでも、送信元のポリシーとブラウザの制限によってはパスが届きます。

GA4の参照元・ノーリファラー・リファラースパム

参照元が「(direct) / (none)」になる理由

GA4の「参照元 / メディア」は、参照URL、UTMパラメータ、自動タグ設定などから判定されます。リファラーが無くてもキャンペーン情報を取得できれば、その流入が「ノーリファラー」になるとは限りません。GA4ヘルプの条件は、参照元が完全一致で(direct)、かつメディアが(not set)または(none)です。(none)だけを探すと(not set)の分を取りこぼします。

多いのはメールのリンク、アプリ内ブラウザ、QRコード、HTTPSからHTTPへの遷移です。ブラウザの挙動は変えられないので、メールやQRコードのリンクにUTMパラメータを付けて計測面から補います。ノーリファラーの比率が高く流入元が読めないときの計測設計は、Webコンサルティング・アクセス解析の支援でも扱っています。

GA4の「除外する参照」の用途と適用範囲

決済代行サービスから戻った際に、そのサービスが参照元として記録される問題は、GA4の「除外する参照」で対処します。条件に一致したイベントにignore_referrer=trueが付き、そのリファラーが参照トラフィックから外れます。設定できるのはデータストリームごとに最大50個です。「参照元を無視する」設定であって、「ノーリファラーを減らす」設定ではありません。

リファラースパムの見分け方

業者が自分のドメイン名を解析レポートの参照元に表示させる手口がリファラースパムです。参照元の値だけではスパムを判別できないため、そのドメインからのセッションのエンゲージメント時間やエンゲージメント率が極端に低くないか、page_viewを伴っているかを手掛かりにします。実際にページを読み込むクローラ型でも、「除外する参照」で外れるのは参照元としての扱いだけで、イベントやセッション自体は残ります。ページを踏まずに計測データだけを送りつけるゴースト型は、サーバーログにアクセスが残らない点で見分けられます。Measurement Protocolを使っているなら、api_secretを公開せず、不正利用が疑われたら作り直してください。

セキュリティ用途でのリファラー制限とその限界

Google CloudのAPIキーのHTTPリファラー制限

ブラウザから直接呼ぶAPIキーは、Google CloudのAPIキーに許可するHTTPリファラーを列挙して保護します。*.example.comは有効ですが、mysubdomain*.example.comのようにURLの途中へ*を混ぜた指定は無効です。ポート番号を書けばそのポートだけに一致します。キーはクエリパラメータでなくx-goog-api-keyヘッダーで渡すよう推奨されています。curlで詐称できる値なので、この制限は「他サイトに埋め込まれて使われる」ことを防ぐ用途に限られ、サーバー間の呼び出しには使えません。

CSRF対策としてのReferer検証は補助

OWASPのCSRF Prevention Cheat Sheetは、Origin／Refererによる送信元検証を「Defense In Depth Techniques」の節に置いています。主防御はトークンです。実装するなら、Originがあればそれを優先し、無いときだけRefererのホストを照合します。照合はオリジン全体で行い、example.orgを前方一致で見てexample.org.attacker.comを通さないようにします。OWASPは、どちらのヘッダーでも送信元を確認できず、有効なCSRFトークンなど別の防御でも検証できない状態変更リクエストを拒否するよう推奨しています。同じ文書のFetch Metadataの節は、ブックマークや直接入力によるトップレベルの遷移（Sec-Fetch-Site: none）を必要に応じて許可するよう書いています。前章のとおりブラウザ以外からは値を詐称でき、ブックマーク経由のGETまで弾くと正規の利用者を止めます。主軸はCSRFトークンとは？仕組み・Double Submit CookieとSPAでの実装に置き、Referer検証は、POST・PUT・PATCH・DELETEなど状態を変更するリクエストへの補助として使ってください。XSSとの違いも含めた全体像はXSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較にあります。

よくある質問

リファラを有効にするにはどうすればよいですか？

まず、サービスのトップページか案内メールの入口URLから開き直し、画面内のボタンで目的の画面まで進んでください。ブックマークやホーム画面から途中の画面を開くとRefererが付かず、サイト側で弾かれることがあります。それでも出る場合はシークレットウィンドウでも試してください。結果の違いは拡張機能やCookieなどを調べる手掛かりになりますが、それだけでは原因を確定できません。Chrome・Safari・Edgeには送信を切り替える設定がありません。

「Referer」と「Referrer」はどちらが正しいのですか？

文脈で違います。リクエストヘッダー名は中央のrを重ねないRefererで、RFC 9110がこの綴りで定義しています。レスポンスヘッダーのReferrer-Policy、HTMLのreferrerpolicy属性、JavaScriptのdocument.referrerは正しい綴りです。

リファラーはJavaScriptで書き換えられますか？

任意の値には書き換えられません。RefererはFetch仕様のforbidden request-headerで、fetch()やXMLHttpRequestのヘッダーに指定しても無視されます。fetch()のreferrerオプションで変えられるのは、同一オリジンのURLか空文字列までです。送る範囲を変えたいときはreferrerpolicy属性かReferrer-Policyヘッダーを使います。curlなどブラウザ以外からは任意の値を送れるため、認証情報としては扱えません。

リファラーが空になるのはどんなときですか？

直接入力・ブックマーク・ホーム画面のアイコン、メールやアプリ内のリンク、HTTPSからHTTPへの遷移、リンク元のno-referrer指定、拡張機能やセキュリティソフトによる削除のいずれかです。なお別サイトからの遷移でオリジンしか届かないのは既定ポリシーの仕様で、不具合ではありません。

リファラー制限とリファラー制御は同じ意味ですか？

立場が逆です。リファラー制御は、自サイトから送る情報の範囲をReferrer-Policyなどで決める送信側の設定です。リファラー制限は、APIキーや画像の直リンク対策のように、受け取ったリファラーでアクセスの可否を判定する受信側の設定で、APIコンソールやnginxのvalid_referersで行います。

関連記事

• nofollowとは？noindex・noopenerとの違いと正しい書き方【2026年時点】
• 同一オリジンとは？判定条件とSame-Origin Policyが止めるもの・止めないもの
• CSRFトークンとは？仕組み・Double Submit CookieとSPAでの実装
• ITPとは？Safariの制限仕様と広告計測への影響・対策【2026年最新】
• サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】