Referrer-Policy 헤더 빌더

Referrer-Policy 헤더는 누군가 링크를 따라 나가거나 페이지가 하위 리소스를 가져올 때, 여러분의 URL이 Referer 요청 헤더에 얼마나 실려 가는지를 제어합니다. 여덟 가지 표준 정책 중 하나를 고르면, 중요한 세 가지 상황에서 수신 서버가 실제로 무엇을 보게 되는지 그대로 보여 줍니다. 같은 출처로 가는 요청, HTTPS로 나가는 교차 출처 요청, 그리고 평문 HTTP로 격하되는 교차 출처 요청입니다. 응답 헤더 형태와 <meta name="referrer"> 형태를 모두 출력하므로, 서버에서 정책을 걸 수도 있고 CDN이 이미 캐시한 HTML 안에서 걸 수도 있습니다.

철자는 이쪽의 오타가 아닙니다. 1996년 HTTP 명세에 Referer로 적혔고, 실수를 알아챘을 때는 고치기에 너무 늦어서, 이후 모든 구현이 그대로 물려받았습니다. 그것을 제어하는 정책 헤더는 철자가 올바르고, 자바스크립트 속성 document.referrer도 마찬가지입니다. 그래서 둘 다 다루는 코드는 한 파일 안에서 두 철자를 정확히 구분해 써야 합니다.

기본값은 사람들이 생각하는 것보다 중요합니다. 바뀌었기 때문입니다. 예전 브라우저는 HTTPS 목적지라면 전체 URL을 보냈지만, 지금의 크롬·파이어폭스·사파리는 strict-origin-when-cross-origin을 기본값으로 씁니다. 같은 출처에는 전체 URL을, 다른 출처에는 스킴과 호스트만, HTTP로 격하될 때는 아무것도 보내지 않습니다. 이 기본값 자체가 이미 합리적인 프라이버시 입장이므로, 헤더를 명시적으로 거는 주된 이유는 더 조이거나 의도를 문서로 남기기 위해서입니다.

더 조일 때의 대가는 따져 볼 만합니다. URL은 경로와 쿼리 문자열에 든 모든 것을 흘립니다. 비밀번호 재설정 토큰, 문서 식별자, 누군가 입력한 검색어까지요. no-referrer는 그것을 완전히 막습니다. 동시에 원래라면 등장했을 모든 분석 대시보드에서 여러분의 사이트를 지우고, 여러분이 보내 준 트래픽을 측정하는 제휴사의 유입 집계를 망가뜨리며, 어떤 서버는 요청 자체를 거부하게 만듭니다. 핫링크 차단이 대개 바로 이 헤더를 확인하는 방식으로 구현되기 때문입니다. strict-origin이 중간 지점입니다. 수신 사이트는 방문자를 여러분이 보냈다는 사실은 알되, 그가 어느 페이지에 있었는지는 알지 못합니다.