---
title: "リファラー（Referer / Referrer）とは？仕組み・リファラー制御と「リファラを有効にしてください」の対処"
url: "https://www.issoh.co.jp/column/details/6995/"
published: 2025-05-28
updated: 2026-10-14
categories: ["Webサイト"]
publisher: "株式会社一創"
---

# リファラー（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](https://www.rfc-editor.org/rfc/rfc9110.html#section-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仕様](https://w3c.github.io/webappsec-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コミュニティへの質問](https://support.google.com/pixelphone/thread/195805036?hl=ja)です。免許更新の予約で、予約確定の画面をホーム画面に保存して開いたところ、「リファラを有効にしてください」と表示されて目的の画面が出なかったという内容です。ホーム画面のアイコンから開くとRefererは付かないため、サイト側のRefererチェックに当たった可能性が高い事例です（サイトの判定条件そのものは公開されていません）。

### 利用者側で確認する順序

1. サービスのトップページか、案内メールに書かれた入口のURLから開き直し、画面内のボタンで目的の画面まで進む。途中の画面への直接アクセスによるRefererの欠落が原因なら、入口から操作し直すことで解消する可能性があります。
2. シークレットウィンドウ（プライベートブラウズ）で同じ手順を試す。拡張機能に加えてCookieやログイン状態も通常ウィンドウと異なるため、通っただけでは原因を確定できません。通常ウィンドウで拡張機能を個別に無効化して再確認します。
3. 拡張機能を1つずつ無効にする。Referer Controlのような書き換え目的の拡張に加え、広告ブロック・プライバシー保護系の拡張もヘッダーを削除できます。Chromeの拡張APIは[declarativeNetRequest](https://developer.chrome.com/docs/extensions/reference/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のドキュメント](https://nginx.org/en/docs/http/ngx%5Fhttp%5Freferer%5Fmodule.html)も「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";
    }
}
```

| 送ったReferer                    | server\_namesのみ | none blocked server\_names |
| ----------------------------- | --------------- | -------------------------- |
| 無し                            | 403             | 200                        |
| https://example.com/top（自サイト） | 200             | 200                        |
| https://other.example/（他サイト）  | 403             | 403                        |
| http(s)で始まらない値                | 403             | 200                        |

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

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

| HTTPSのPOSTに付けたヘッダー       | 結果                                         |
| ------------------------ | ------------------------------------------ |
| Origin・Refererとも無し       | 403（Referer checking failed – no Referer.） |
| Referer＝同一オリジン           | 200                                        |
| Referer＝別オリジン            | 403（does not match any trusted origins）    |
| Origin＝同一オリジン（Referer無し） | 200                                        |
| Origin＝null              | 403（Origin checking failed – null）         |

Refererが無いときの403画面には、Refererを「please re-enable them, at least for this site」と再有効化を求める英文が出ます。各社の「リファラを有効にしてください」と同じ趣旨の案内です。最後の行は、サイト自身が`no-referrer`を指定した場合です。[Fetch仕様](https://fetch.spec.whatwg.org/#origin-header)では、ポリシーが`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で既定を切り替え](https://developer.chrome.com/blog/referrer-policy-new-chrome-default)、仕様の既定が改まったのは2020年11月です。旧既定に戻す管理者ポリシー`ForceLegacyDefaultReferrerPolicy`はChrome 80〜87だけの対応で、88で削除されました。

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

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

| 値                                   | 同一オリジン | 別オリジン（HTTPS→HTTPS） | HTTPS→HTTP |
| ----------------------------------- | ------ | ------------------ | ---------- |
| no-referrer                         | 送らない   | 送らない               | 送らない       |
| no-referrer-when-downgrade          | 完全URL  | 完全URL              | 送らない       |
| origin                              | オリジン   | オリジン               | オリジン       |
| origin-when-cross-origin            | 完全URL  | オリジン               | オリジン       |
| same-origin                         | 完全URL  | 送らない               | 送らない       |
| strict-origin                       | オリジン   | オリジン               | 送らない       |
| strict-origin-when-cross-origin（既定） | 完全URL  | オリジン               | 送らない       |
| unsafe-url                          | 完全URL  | 完全URL              | 完全URL      |

「完全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](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fheaders%5Fmodule.html#add%5Fheader)は、`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防御の実装判断を解説](/tech/details/16358/)で扱っています。

### 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との違いと正しい書き方](/column/details/4879/)で整理しています。

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

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

- Safari：[WebKitのトラッキング防止](https://webkit.org/tracking-prevention/)は「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.sendRefererHeader           | 2    | 0=送らない／1=クリック時のみ／2=画像でも送る    |
| network.http.referer.defaultPolicy       | 2    | 既定のポリシー（表の下に対応）              |
| network.http.referer.XOriginPolicy       | 0    | 0=常に送る／1=ベースドメイン一致時／2=ホスト一致時 |
| network.http.referer.trimmingPolicy      | 0    | 0=完全URI／1=パスまで／2=オリジンまで      |
| network.http.referer.referrerLengthLimit | 4096 | 上限バイト数（0で無制限）                |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[OWASPのCSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site%5FRequest%5FForgery%5FPrevention%5FCheat%5FSheet.html)は、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での実装](/column/details/3984/)に置き、Referer検証は、POST・PUT・PATCH・DELETEなど状態を変更するリクエストへの補助として使ってください。XSSとの違いも含めた全体像は[XSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較](/tech/details/4109/)にあります。

## よくある質問

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

まず、サービスのトップページか案内メールの入口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年時点】](/column/details/4879/)
- [同一オリジンとは？判定条件とSame-Origin Policyが止めるもの・止めないもの](/tech/details/7544/)
- [CSRFトークンとは？仕組み・Double Submit CookieとSPAでの実装](/column/details/3984/)
- [ITPとは？Safariの制限仕様と広告計測への影響・対策【2026年最新】](/column/details/5114/)
- [サードパーティCookieとは？仕組みとブラウザ別の扱いを解説【2026年最新】](/column/details/4787/)

---

出典: [リファラー（Referer / Referrer）とは？仕組み・リファラー制御と「リファラを有効にしてください」の対処](<https://www.issoh.co.jp/column/details/6995/>)（株式会社一創）