Loading article…
HTTPにおいて、「Referer 」（「 Referrer」[ 1 ]のスペルミス）は、リソースが要求されたウェブページのアドレス（つまり、URIまたはIRI ）を識別するオプションのHTTPヘッダーフィールドです。リファラーを確認することで、新しいウェブページを提供するサーバーは、要求の発信元を知ることができます。
最も一般的な状況では、これは、ユーザーがウェブブラウザでハイパーリンクをクリックすると、ブラウザが目的のウェブページを保持しているサーバーにリクエストを送信することを意味し、そのリクエストにはRefererフィールドが含まれる場合があります。Refererフィールドは、ユーザーが最後に閲覧していたページ（リンクをクリックしたページ）を示します。
Web サイトやWeb サーバーは 、プロモーションや統計目的で、ユーザーがリンクをたどった Web ページを識別するために、受信したRefererフィールドの内容をログに記録します。これはユーザーのプライバシーの喪失につながり、セキュリティリスクを引き起こす可能性があります。[ 2 ]セキュリティ リスクを軽減するために、ブラウザは Referer で送信される情報の量を着実に減らしてきました。2021 年 3 月現在、デフォルトではChrome、[ 3 ] ChromiumベースのEdge、Firefox、[ 4 ] Safari [ 5 ]はクロス オリジン リクエストでオリジンのみを送信し、ドメイン名以外のすべてを削除するようになっています。
「referer」のスペルミスは、コンピュータ科学者のフィリップ・ハラム＝ベイカーがHTTP仕様に「Referer」ヘッダーフィールドを組み込むための最初の提案で導入されました。[ 6 ] [ 7 ]このスペルミスは、Request for Comments標準文書RFC 1945 [ 8 ]に組み込まれた時点（1996年5月）までに定着しました（当時「HTTP/1.0」と呼ばれるプロトコルの一般的な使用法を反映しています）。文書の共同執筆者であるロイ・フィールディングは、1995年3月に、当時の標準的なUnixスペルチェッカーでは「どちらも（refererまたはreferrer）理解されない」と述べています。 [ 9 ]その後、 「Referer」はHTTPリファラーについて議論する際に業界で広く使用されるスペルになりました。ただし、このスペルミスの使用は普遍的ではなく、 HTTPヘッダーやDocument Object Modelなどの一部のWeb仕様では正しいスペル「referrer」が使用されています。[ 2 ]Referrer-Policy
ウェブページを訪問する際、リファラーまたは参照元ページとは、リンクをたどってアクセスした前のウェブページのURLのことです。
より一般的には、リファラーとは、このリクエストにつながった前のアイテムの URL のことです。たとえば、画像のリファラーは通常、画像が表示されるHTMLページです。リファラー フィールドは、Web ブラウザから Web サーバーに送信される HTTP リクエストのオプションの部分です。[ 10 ]
多くのウェブサイトは、ユーザーを追跡する試みの一環として、リファラーをログに記録しています。ほとんどのウェブログ分析ソフトウェアはこの情報を処理できます。リファラー情報はプライバシーを侵害する可能性があるため、一部のウェブブラウザでは、ユーザーがリファラー情報の送信を無効にできるようにしています。[ 11 ]一部のプロキシおよびファイアウォールソフトウェアも、非公開のウェブサイトの場所が漏洩しないように、リファラー情報をフィルタリングします。これにより、問題が発生する可能性があります。一部のウェブサーバーは、ディープリンクや画像の不正使用（帯域幅の盗難）を防ぐために、適切なリファラー情報を送信しないウェブブラウザに対してウェブサイトの一部をブロックします。一部のプロキシソフトウェアは、ターゲットウェブサイトのトップレベルアドレスをリファラーとして提供する機能があり、これらの問題を軽減しますが、場合によってはユーザーの最後に訪問したウェブページが漏洩する可能性があります。
多くのブログは、自分にリンクを貼ってくれた人々にリンクを返して議論を広げるために、リファラー情報を公開しています。これが、リファラースパムの増加につながっています。リファラースパムとは、スパマーのウェブサイトを宣伝するために、偽のリファラー情報を送信する行為です。
JavaScriptの document.referrer を使用してクライアント側でリファラー情報にアクセスすることが可能です。[ 12 ]これは、たとえばユーザーの検索エンジンのクエリに基づいて Web ページを個別化するために使用できます。ただし、 HTTPS でGoogle 検索を使用する場合など、リファラーフィールドには検索キーワードが必ずしも含まれているとは限りません。 [ 13 ]
ほとんどのウェブサーバーはすべてのトラフィックのログを保持し、各リクエストに対してウェブブラウザから送信された HTTP リファラーを記録します。これはプライバシーに関する多くの懸念を引き起こし、その結果、ウェブサーバーに実際の参照 URL が送信されるのを防ぐためのシステムが数多く開発されてきました。これらのシステムは、リファラー フィールドを空白にするか、不正確なデータに置き換えることによって機能します。一般的に、インターネット セキュリティスイートはリファラー データを空白にしますが、ウェブ ベースのサーバーはそれを偽の URL（通常はサーバー自身の URL）に置き換えます。これにより、リファラー スパムの問題が発生します。両方の方法の技術的な詳細はかなり一貫しています。ソフトウェア アプリケーションはプロキシ サーバーとして機能し、HTTP リクエストを操作しますが、ウェブ ベースの方法は、フレーム内に Web サイトをロードし、ウェブブラウザに Web サイト アドレスのリファラー URL を送信させます。一部のウェブ ブラウザは、リクエスト ヘッダーのリファラー フィールドをオフにするオプションをユーザーに提供します。[ 11 ]
ほとんどのウェブブラウザは、「更新」フィールドを使用してリダイレクトするように指示された場合、リファラーフィールドを送信しません。これには、Operaの一部のバージョンや多くのモバイルウェブブラウザは含まれません。ただし、このリダイレクト方法は、ワールドワイドウェブコンソーシアム(W3C) によって推奨されていません。[ 14 ]
ウェブサイトがHTTPセキュア（HTTPS）接続からアクセスされ、リンクが別のセキュアな場所以外の場所を指している場合、リファラーフィールドは送信されません。[ 10 ]
HTML5標準では、rel="noreferrer"ユーザーエージェントにリファラーを送信しないように指示する属性/値のサポートが追加されました。 [ 15 ]
別の参照元隠蔽方法として、元のリンクURLを、メタタグで元のURLにリダイレクトされる小さなHTMLページを含むデータURIスキームベースのURLに変換する方法があります。ユーザーがそのページからリダイレクトされると、元の参照元は隠蔽されます。data:
コンテンツセキュリティポリシー標準バージョン1.1では、リファラーヘッダーに関するブラウザの動作をより詳細に制御できる新しいリファラーディレクティブが導入されました。具体的には、ウェブマスターがブラウザにリファラーを全くブロックしない、同じオリジンで移動する場合にのみ表示するなどと指示することができます。[ 16 ]