HTTP 리퍼러

HTTP에서 "" ("Referrer"의 오타)는 리소스를 요청한 웹 페이지의 주소(즉, URI 또는 IRI)를 식별하는 선택적인 HTTP 헤더 필드이다. 리퍼러를 확인함으로써 새 웹 페이지를 제공하는 서버는 요청이 어디에서 시작되었는지 확인할 수 있다.

가장 일반적인 상황에서, 이는 사용자가 웹 브라우저에서 하이퍼링크를 클릭하여 브라우저가 대상 웹 페이지를 보유한 서버에 요청을 보낼 때, 해당 요청에 사용자가 직전에 머물렀던 페이지(링크를 클릭한 페이지)를 나타내는  필드가 포함될 수 있음을 의미한다.

웹사이트와 웹 서버는 홍보 또는 통계 목적으로 사용자가 어떤 웹 페이지의 링크를 타고 들어왔는지 식별하기 위해 수신된  필드의 내용을 로그에 기록한다. 이는 사용자의 정보 프라이버시 상실을 초래하며 보안 위험을 유발할 수 있다. 보안 위험을 완화하기 위해 브라우저들은 리퍼러(Referer)로 전송되는 정보의 양을 꾸준히 줄여왔다. 2021년 3월 기준으로 크롬, 크로미엄 기반의 엣지, 파이어폭스, 사파리는 교차 출처(cross-origin) 요청 시 도메인 이름 이외의 모든 정보를 제거하고 오리진(origin)만 전송하는 것을 기본값으로 한다.

 어원 
referrer의 오타는 컴퓨터 과학자 필립 할람베이커(Phillip Hallam-Baker)가 HTTP 규격에  헤더 필드를 포함시키기 위해 제안한 원안에서 처음 도입되었다. 이 오타는 1996년 5월 RFC 표준 문서인 RFC 1945(당시 "HTTP/1.0"으로 불린 프로토콜의 일반적인 사용법을 반영함)에 통합될 때 확정되었다. 문서의 공동 저자인 로이 필딩(Roy Fielding)은 1995년 3월에 당시 표준 유닉스 맞춤법 검사기가 ""와 "referrer" 둘 다 인식하지 못했다고 언급한 바 있다. 이후 는 HTTP 리퍼러를 논할 때 업계에서 널리 사용되는 철자가 되었다. 다만 오타의 사용이 보편적인 것은 아니어서, Referrer-Policy HTTP 헤더나 문서 객체 모델과 같은 일부 웹 규격에서는 올바른 철자인 "referrer"가 사용되기도 한다.

 상세 내용 
웹 페이지를 방문할 때, 리퍼러 또는 참조 페이지는 링크를 따라온 이전 웹 페이지의 URL을 의미한다.

더 일반적으로 리퍼러는 현재 요청으로 이어진 이전 항목의 URL이다. 예를 들어, 이미지의 리퍼러는 일반적으로 해당 이미지가 표시될 HTML 페이지이다. 리퍼러 필드는 웹 브라우저가 웹 서버로 보내는 HTTP 요청의 선택적인 부분이다.

많은 웹사이트는 사용자 추적 시도의 일환으로 리퍼러를 기록한다. 대부분의 웹 로그 분석 소프트웨어는 이 정보를 처리할 수 있다. 리퍼러 정보는 프라이버시를 침해할 수 있기 때문에, 일부 웹 브라우저는 사용자가 리퍼러 정보 전송을 비활성화할 수 있도록 허용한다. 일부 프록시 서버 및 방화벽 소프트웨어 또한 비공개 웹사이트의 위치 유출을 방지하기 위해 리퍼러 정보를 필터링한다. 이는 반대로 문제를 일으킬 수도 있다. 일부 웹 서버는 딥 링크나 이미지의 무단 사용(대역폭 도난)을 방지하기 위해 올바른 리퍼러 정보를 보내지 않는 웹 브라우저의 접속을 차단하기도 한다. 일부 프록시 소프트웨어는 대상 웹사이트의 최상위 주소를 리퍼러로 제공하는 기능을 갖추고 있어 이러한 문제를 줄이면서도 사용자가 마지막으로 방문한 웹 페이지가 노출되는 것을 방지한다.

많은 블로그는 자신들에게 링크를 건 사람들과 다시 연결하여 대화를 확장하기 위해 리퍼러 정보를 공개한다. 이는 결과적으로 스패머의 웹사이트를 홍보하기 위해 가짜 리퍼러 정보를 보내는 리퍼러 스팸의 증가로 이어졌다.

자바스크립트의 document.referrer를 사용하여 클라이언트 측에서 리퍼러 정보에 접근하는 것이 가능하다. 이는 예를 들어 사용자의 검색 엔진 쿼리를 기반으로 웹 페이지를 개별화하는 데 사용될 수 있다. 그러나 HTTPS를 사용하는 구글 검색과 같은 경우 리퍼러 필드에 검색 키워드가 항상 포함되는 것은 아니다.

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

대부분의 웹 브라우저는 "Refresh" 필드를 사용하여 리디렉션 명령을 받았을 때 리퍼러 필드를 보내지 않는다. 여기에는 오페라의 일부 버전과 많은 모바일 웹 브라우저가 포함되지 않는다. 그러나 이러한 리디렉션 방식은 월드 와이드 웹 컨소시엄(W3C)에서 권장하지 않는다.

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

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

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

콘텐츠 보안 정책 표준 버전 1.1에서는 리퍼러 헤더와 관련하여 브라우저의 동작을 더 세밀하게 제어할 수 있는 새로운 리퍼러 지시문을 도입했다. 구체적으로 웹마스터가 브라우저에 리퍼러를 전혀 차단하지 않도록 하거나, 동일한 오리진으로 이동할 때만 노출하도록 지시하는 등의 설정이 가능하다.

 각주 

 외부 링크 
 RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
 RFC 3987: Internationalized Resource Identifiers (IRIs)

분류:URL
분류:URI 스킴
분류:HTTP 헤더