본문으로 이동

HTTP 리퍼러

위키백과, 우리 모두의 백과사전.

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

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

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

어원

[편집]

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

상세 내용

[편집]

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

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

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

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

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

리퍼러 숨기기

[편집]

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

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

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

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

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

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

각주

[편집]
  1. ↑ Gourley, David; Totty, Brian; Sayer, Marjorie; Aggarwal, Anshu; Reddy, Sailu (2002년 9월 27일). 《HTTP:The Definitive Guide》. "O'Reilly Media, Inc.". ISBN 9781565925090.
  2. 1 2 “Does your website have a leak?”. 《ICO Blog》. 2015년 9월 16일. 2018년 5월 24일에 원본 문서에서 보존된 문서. 2018년 8월 16일에 확인함.
  3. ↑ “Referrer Policy: Default to strict-origin-when-cross-origin - Chrome Platform Status”. 《www.chromestatus.com》. 2021년 3월 23일에 확인함.
  4. ↑ Lee, Dimi; Kerschbaumer, Christoph (2021년 3월 22일). “Firefox 87 trims HTTP Referrers by default to protect user privacy” (미국 영어). 《Mozilla Security Blog》. 2021년 3월 23일에 확인함.
  5. ↑ Wilander, John (2019년 12월 10일). “Preventing Tracking Prevention Tracking”. 《WebKit blog》.
  6. ↑ Hallam-Baker, Phillip (2000년 9월 21일). “Re: Is Al Gore The Father of the Internet?”. 뉴스그룹: alt.folklore.computers. 2013년 3월 20일에 확인함.
  7. ↑ Hallam-Baker, Phillip. “Re: Referer: (sic)”. 《W3C Public mailing list archives》. 2024년 2월 19일에 원본 문서에서 보존된 문서. 2024년 2월 19일에 확인함.
  8. ↑ Berners-Lee, T.; Fielding, R.; Frystyk, H. (May 1996). Hypertext Transfer Protocol -- HTTP/1.0. IETF. doi:10.17487/RFC1945. RFC 1945. https://tools.ietf.org/html/rfc1945.
  9. ↑ Fielding, Roy (1995년 3월 9일). “Re: referer: (sic)” (메일링 리스트). 《ietf-http-wg-old》. 2013년 3월 20일에 확인함.
  10. 1 2 Fielding, R.; Reschke, J. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content: referrer (RFC 7231 § 5.5.2). IETF. sec. 5.5.2. doi:10.17487/RFC7231. RFC 7231. https://tools.ietf.org/html/rfc7231#section-5.5.2. Retrieved 2014-07-26.
  11. 1 2 “Network.http.sendRefererHeader”. MozillaZine. 2007년 6월 10일. 2015년 5월 27일에 확인함.
  12. ↑ “HTML DOM Document referrer Property”. W3Schools. 2013년 3월 20일에 확인함.
  13. ↑ Gundersen, Bret (2011년 10월 19일). “The Impact of Google Encrypted Search”. Adobe Digital Marketing Blog. 2021년 3월 17일에 확인함.
  14. ↑ “HTML Techniques for Web Content Accessibility Guidelines 1.0: The META element”. W3C. 2000년 11월 6일. 2013년 3월 20일에 확인함.
  15. ↑ “4.12 Links — HTML Living Standard: 4.12.5.8 Link type "noreferrer"”. WHATWG. 2016년 2월 19일. 2016년 2월 19일에 확인함.
  16. ↑ “Content Security Policy Level 2”. W3. 2014. 2014년 12월 8일에 확인함.

외부 링크

[편집]
  • RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
  • RFC 3987: Internationalized Resource Identifiers (IRIs)
원본 주소 "https://ko.wikipedia.org/w/index.php?title=HTTP_리퍼러&oldid=41428342"