HTTP リファラー

HTTPでは、「リファラー」（「 Referrer」のスペルミス^[1]）は、リソースが要求されたウェブページのアドレス（つまり、URIまたはIRI ）を識別するオプションのHTTPヘッダーフィールドです。リファラーをチェックすることで、新しいウェブページを提供するサーバーは、リクエストの発信元を確認できます。

最も一般的な状況では、ユーザーがWeb ブラウザーでハイパーリンクをクリックすると、ブラウザーが宛先の Web ページを保持しているサーバーに要求を送信し、その要求に Referer フィールドが含まれる場合があります。このフィールドは、ユーザーが最後に表示していたページ (リンクをクリックしたページ) を示します。

ウェブサイトやウェブサーバーは、 受信した Referer フィールドの内容をログに記録し、ユーザーがリンクをたどったウェブページを識別して、宣伝や統計の目的で使用します。 ^[要出典]これにより、ユーザーのプライバシーが失われ、セキュリティ上のリスクが発生する可能性があります。^[2]セキュリティ上のリスクを軽減するために、ブラウザは Referer で送信される情報の量を着実に削減しています。2021 年 3 月現在、Chrome、^[3] ChromiumベースのEdge、Firefox、^[4] Safari ^[5]は、デフォルトでクロスオリジン リクエストでオリジンのみを送信し、ドメイン名以外のすべてを削除します。

referrerのスペルミスは、コンピュータ科学者Phillip Hallam-BakerがHTTP仕様に「Referer」ヘッダー フィールドを組み込むという最初の提案で導入されました。^{[6] [7]}このスペルミスは、Request for Comments標準文書 RFC 1945 ^{[8] (当時「HTTP/1.0} 」と呼ばれていたプロトコルの一般的な使用法を反映している) に組み込まれた時点 (1996 年 5 月) で確定しました。文書の共著者Roy Fielding は、1995 年 3 月に「どちらの (referer または referrer) も、当時の標準Unix スペル チェッカーでは理解されない」と述べました。 ^[9]「Referer」は、それ以来、HTTP リファラーについて議論する際に業界で広く使用されるスペルになりました。ただし、スペルミスの使用は普遍的ではなく、正しいスペルである「referrer」は、HTTPReferrer-PolicyヘッダーやDocument Object Modelなどの一部の Web 仕様で使用されています。^[2]

Web ページにアクセスすると、リファラーまたは参照ページは、リンクをたどった前の Web ページの URL になります。

より一般的には、リファラーとは、このリクエストにつながった前のアイテムの URL です。たとえば、画像のリファラーは通常、その画像が表示されるHTMLページです。リファラー フィールドは、 Web ブラウザから Web サーバーに送信される HTTP リクエストのオプション部分です。^[10]

多くのウェブサイトは、ユーザーを追跡する試みの一環としてリファラーを記録します。ほとんどのウェブログ分析ソフトウェアはこの情報を処理できます。リファラー情報はプライバシーを侵害する可能性があるため、一部のウェブブラウザでは、ユーザーがリファラー情報の送信を無効にできます。^[11]一部のプロキシおよびファイアウォールソフトウェアも、非公開のウェブサイトの場所が漏洩するのを防ぐために、リファラー情報をフィルタリングします。これにより、問題が発生する可能性があります。一部のウェブサーバーは、ディープリンクや画像の不正使用（帯域幅の盗難）を防ぐために、適切なリファラー情報を送信しないウェブブラウザーに対してウェブサイトの一部をブロックします。一部のプロキシソフトウェアには、ターゲットウェブサイトのトップレベルアドレスをリファラーとして提供する機能があり、これによりこれらの問題が軽減されますが、場合によってはユーザーが最後に訪問したウェブページが漏洩する可能性があります。

多くのブログは、リンクを張っている人にリンクを返し、会話を広げるためにリファラー情報を公開しています。これにより、スパマーの Web サイトを宣伝するために偽のリファラー情報を送信するリファラー スパムが増加しています。

JavaScriptのdocument.referrerを使用すると、クライアント側でリファラー情報にアクセスすることができます。^[12]これは、たとえば、ユーザーの検索エンジンクエリに基づいてWebページを個別化するために使用できます。ただし、 HTTPSでGoogle検索を使用する場合など、リファラーフィールドに検索キーワードが常に含まれるわけではありません。^[13]

ほとんどのウェブ サーバーはすべてのトラフィックのログを保持し、リクエストごとにウェブ ブラウザーから送信された HTTP リファラーを記録します。これによりプライバシーに関する懸念がいくつか生じ、その結果、ウェブ サーバーに実際の参照 URL が送信されないようにするシステムがいくつか開発されました。これらのシステムは、リファラー フィールドを空白にするか、不正確なデータに置き換えることによって機能します。通常、インターネット セキュリティスイートはリファラー データを空白にしますが、ウェブベースのサーバーはそれを偽の URL (通常は独自の URL) に置き換えます。これにより、リファラー スパムの問題が生じます。両方の方法の技術的な詳細はほぼ一貫しています。ソフトウェア アプリケーションはプロキシ サーバーとして機能し、HTTP リクエストを操作します。一方、ウェブベースの方法はフレーム内に Web サイトを読み込み、Web ブラウザーが Web サイト アドレスのリファラー URL を送信します。一部の Web ブラウザーでは、ユーザーがリクエスト ヘッダーのリファラー フィールドをオフにするオプションを提供しています。^[11]

ほとんどのウェブブラウザは、「更新」フィールドを使用してリダイレクトするように指示された場合、リファラフィールドを送信しません。これには、Operaの一部のバージョンと多くのモバイルウェブブラウザは含まれません。ただし、このリダイレクト方法は、ワールドワイドウェブコンソーシアム（W3C）によって推奨されていません。^[14]

ウェブサイトがHTTPセキュア（HTTPS）接続からアクセスされ、リンクが別の安全な場所以外の場所を指している場合、リファラーフィールドは送信されません。^[10]

HTML5標準でrel="noreferrer"は、ユーザーエージェントにリファラを送信しないように指示する属性/値のサポートが追加されました。 ^[15]

リファラーを隠すもう 1 つの方法は、元のリンク URL を、元の URL へのメタ更新を含む小さな HTML ページを含むData URI スキーム ベースの URL に変換することです。ユーザーがそのページからリダイレクトされると、元のリファラーは隠されます。 data:

コンテンツセキュリティポリシー標準バージョン1.1では、リファラヘッダーに関するブラウザの動作をより細かく制御できる新しいリファラディレクティブが導入されました。具体的には、ウェブマスターがブラウザにリファラをまったくブロックしないように指示したり、同じオリジンで移動する場合にのみリファラを表示するように指示したりできるようになりました。 ^[16]

無料辞書の Wiktionary でreferer またはreferrer を調べてください。

• RFC 1945: ハイパーテキスト転送プロトコル -- HTTP/1.0
• RFC 7231: ハイパーテキスト転送プロトコル (HTTP/1.1): セマンティクスとコンテンツ
• RFC 3987: 国際化リソース識別子 (IRI)
• リファラーポリシー - W3C 編集者草案