HTTP 리퍼러

3. 상세

웹 브라우저가 웹 서버에 보내는 HTTP 요청에는 리퍼러(referrer) 필드가 포함될 수 있는데, 이는 사용자가 링크를 클릭하여 다른 웹 페이지로 이동할 때 이전 웹 페이지의 URL을 담고 있다. 웹 페이지 내 이미지와 같은 특정 요소의 경우, 해당 요소를 포함하는 HTML 페이지의 URL이 리퍼러가 된다.

많은 웹사이트는 사용자를 웹 추적하기 위해 리퍼러를 기록하며, 대부분의 웹 로그 분석 소프트웨어는 이 정보를 처리할 수 있다. 리퍼러 정보는 개인 정보 보호 문제를 일으킬 수 있으므로, 일부 웹 브라우저는 리퍼러 정보 전송을 비활성화하는 기능을 제공한다. 프록시 서버나 방화벽 (네트워킹) 소프트웨어는 리퍼러 정보를 필터링하여 비공개 웹사이트 위치 유출을 막기도 한다.

하지만 리퍼러 정보 필터링은 문제를 야기할 수 있는데, 일부 웹 서버는 딥 링크 및 무단 이미지 사용(대역폭 도용)을 방지하기 위해 올바른 리퍼러 정보를 보내지 않는 웹 브라우저에 대해 웹사이트의 일부를 차단하기 때문이다. 이러한 문제를 줄이기 위해 일부 프록시 소프트웨어는 대상 웹사이트의 최상위 주소를 리퍼러로 제공하기도 하지만, 이는 사용자가 마지막으로 방문한 웹 페이지를 공개할 수 있다.

많은 블로그는 상호 링크를 통해 대화를 확장하기 위해 리퍼러 정보를 공개한다. 그러나 이는 스패머가 자신의 웹사이트를 홍보하기 위해 가짜 리퍼러 정보를 보내는 리퍼러 스팸의 증가로 이어지기도 한다.

자바스크립트의 document.referrer를 사용하면 클라이언트 측에서 리퍼러 정보에 접근할 수 있다.

4. 리퍼러 숨김

대부분의 웹 서버는 모든 트래픽의 로그를 기록하며, 각 요청에 대해 웹 브라우저가 보낸 HTTP 리퍼러를 기록한다. 이는 여러 가지 개인 정보 보호 문제를 야기하며, 그 결과 웹 서버가 실제 참조 URL을 전송받지 못하도록 하는 여러 시스템이 개발되었다. 이러한 시스템은 리퍼러 필드를 비우거나 부정확한 데이터로 대체하는 방식으로 작동한다. 일반적으로, 인터넷 보안 제품군은 리퍼러 데이터를 제거하는 반면, 웹 기반 서버는 이를 가짜 URL(대개 자체 URL)로 대체한다. 이는 리퍼러 스팸 문제를 야기한다. 두 방법의 기술적 세부 사항은 상당히 일관되는데, 소프트웨어 애플리케이션은 프록시 서버 역할을 하며 HTTP 요청을 조작하는 반면, 웹 기반 방법은 웹사이트를 프레임 내에 로드하여 웹 브라우저가 자체 웹사이트 주소의 리퍼러 URL을 전송하도록 한다. 일부 웹 브라우저는 사용자에게 요청 헤더에서 리퍼러 필드를 끄는 옵션을 제공한다.

대부분의 웹 브라우저는 "새로 고침" 필드를 사용하여 리디렉션하도록 지시받으면 리퍼러 필드를 전송하지 않는다. 여기에는 일부 버전의 오페라와 많은 모바일 웹 브라우저가 포함되지 않는다. 그러나 이 리디렉션 방법은 월드 와이드 웹 컨소시엄(W3C)에서 권장하지 않는다.

웹사이트가 HTTPS 연결을 통해 액세스되고 링크가 다른 보안 위치가 아닌 곳을 가리키는 경우, 리퍼러 필드는 전송되지 않는다.

HTML5 표준은 사용자 에이전트에게 리퍼러를 전송하지 않도록 지시하는 속성/값 `rel="noreferrer"`에 대한 지원을 추가했다.

또 다른 리퍼러 숨기기 방법은 원래 링크 URL을 데이터 URI 스킴 기반 URL로 변환하여 원래 URL로의 메타 새로 고침이 있는 작은 HTML 페이지를 포함하는 것이다. 사용자가 `data:` 페이지에서 리디렉션될 때 원래 리퍼러는 숨겨진다.

콘텐츠 보안 정책 표준 버전 1.1은 리퍼러 헤더와 관련하여 브라우저의 동작을 더 많이 제어할 수 있는 새로운 ''리퍼러'' 지시어를 도입했다. 특히 웹마스터가 브라우저에게 리퍼러를 전혀 차단하지 않도록 하거나, 동일한 출처로 이동할 때만 표시하도록 지시할 수 있다.

4. 1. 리퍼러와 한국의 개인정보보호

5. 리퍼러 스푸핑

성인 사이트 등 유료 사이트는 콘텐츠 보호를 위해 리퍼러 정보를 이용하는 경우가 많다.^[5] 이러한 사이트는 로그인하지 않으면 접근할 수 없는 극소수의 페이지만을 허용하여 콘텐츠를 보호한다. 이는 협력 관계에 있는 성인 사이트 간의 소재 공유를 용이하게 한다. 리퍼러 스푸핑은 이러한 사이트에 자유롭게 접근하기 위한 수단으로 활용된다.

6. 리퍼러 정책

웹사이트는 리퍼러 전송 여부를 제어하는 메커니즘으로, '''리퍼러 정책'''을 구현하고 있다.

7. 철자

referrer의 오기는 컴퓨터 과학자 필립 핼럼-베이커(Phillip Hallam-Baker)가 Referer|리퍼러^영어 헤더 필드를 HTTP 규격에 포함시키기 위한 최초 제안에서 비롯되었다. 이 오기는 Request for Comments 표준 문서 RFC 1945 (1996년 5월)에 포함될 때 확정되었다. 문서 공동 저자인 로이 필딩(Roy Fielding)은 1995년 3월에 referer|리퍼러^영어나 referrer 둘 다 당시 표준 유닉스 철자 검사기(Unix spell checker)에서 인식되지 않는다고 언급했다. Referer|리퍼러^영어는 이후 HTTP 리퍼러를 논의할 때 업계에서 널리 사용되는 철자가 되었다. 하지만 이 오용의 사용이 보편적인 것은 아니며, `Referrer-Policy` HTTP 헤더 또는 문서 객체 모델과 같은 일부 웹 사양에서는 올바른 철자인 "referrer"를 사용한다.

원래 "참조자"라는 의미의 영어 단어는 referrer|리퍼러^영어이지만, HTTP 리퍼러의 경우 의도적으로 referer|리퍼러^영어라고 표기한다. 이는 HTTP가 제정되었을 때 헤더 이름을 잘못된 철자로 적었고, 그것이 지금도 사용되고 있다는 역사적인 경위 때문이다.

사양상의 헤더명은 referer|리퍼러^영어이므로, HTTP 헤더를 직접 다루는 소프트웨어 프로그램의 경우, referrer|리퍼러^영어라고 표기하면 의도대로 동작하지 않을 수 있다.

참조

_[1] 웹사이트 Preventing Tracking Prevention Tracking https://webkit.org/b[...] 2019-12-10
_[2] 문서 通常は[[Uniform Resource Locator|URL]]だが、より汎用的には[[Uniform Resource Identifier|URI]]や[[国際化と地域化|国際化]]された[[Internationalized Resource Identifier|IRI]]
_[3] 문서 dereferer
_[4] 문서 The Referer[sic] request-header field allows the client to specify […] the address (URI) of the resource from which the Request-URI was obtained […] IETF RFC
_[5] 뉴스 アクセス解析を利用した“悪意”ある宣伝手法「リファラースパム」 http://markezine.jp/[...] Markezine 2008-08-20
_[6] mozillaZine Network.http.sendRefererHeader http://kb.mozillazin[...]
_[7] 웹사이트 HTML Standard .5.5 Referrer policy attributes https://html.spec.wh[...] 2017-06-22
_[8] 웹사이트 HTML Standard 日本語訳 2.5.5 リファラーポリシー属性 https://momdo.github[...] 2017-06-04
_[9] 웹사이트 Protecting Privacy with Referrers https://www.facebook[...] 2010-05-24
_[10] HTML Techniques for Web Content Accessibility Guidelines 1.0 1.1.3 The META element https://www.w3.org/T[...]
_[11] 웹인용 HTTP:The Definitive Guide https://books.google[...]