HTTP Header Referrer 관리 및 Google Chrome 정책

A 사이트에서 B 사이트를 연결할 때 HTTP 헤더의 Referrer에는 요청된 웹사이트의 URL이나 도메인이 들어감.

Referrer를 어떤 형태로 보낼 것인지는 요청 사이트에서 meta tag로 제어할 수 있다.

아래는 NAVER의 블로그 서비스에 정의된 Referrer 정책이다.

Referrer 정책이 “always” 로 지정되어 있고, 이는 NAVER 블로그에서 다른 웹사이트로 HTTP 요청을 보낼 때 항상 Referrer 에 Full URL을 전송한다는 의미이다.

HTTP 요청의 헤더에서 Referrer 항목을 로그로 출력해보면 위와 같이 요청 사이트의 URL이 나온다.

NAVER 블로그에서 Link로 연결된 모든 웹사이트에서는 Referrer 주소를 이와 같이 취득이 가능하다 는 얘기다.

Referrer는 통상 Apache나 Nginx 등 웹서버에서 정책적으로 관리하지만 HTML의 meta tag로 제어할 경우에는 아래와 같은 옵션으로 관리한다.

브라우저별 지원 여부 : https://caniuse.com/mdn-html_elements_meta_name_referrer

Chrome에서는 no-referrer-when-downgrade 를 기본 정책으로 사용하였다가 85버전부터는 strict-origin-when-cross-origin 으로 정책을 변경하였고, 타 브라우저도 보안 강화 흐름에 따라 점차 엄격한 기준으로 변경할 것이 확실시됨.

Notice 원문 : https://developer.chrome.com/blog/referrer-policy-new-chrome-default/

Up until recently, no-referrer-when-downgrade has been a widespread default policy across browsers. But now many browsers are in some stage of moving to more privacy-enhancing defaults. Chrome plans to switch its default policy from no-referrer-when-downgrade to strict-origin-when-cross-origin, starting in version 85.

HTTP 헤더의 Referer 정보를 사용한 개발 시 이슈

• Chrome 웹브라우저의 기본 정책 상으로는 요청 사이트의 Full URL을 알 수 없음.
• 도메인 단위의 필터링은 가능할 수 있으나, 더 세분화된 path 레벨의 필터링은 보편적으로 어려움.
• Referrer 정책은 웹서버의 설정으로 통해 제어하는 것이 일반적이기 때문에, 단순 HTML 태그의 내용만으로는 단정지을 수 없고, 사이트마다 CASE를 만들어 사전 테스트가 필요함.
• 원하는 결과가 나오지 않았을 때는 해당되는 요청 웹사이트의 개발/관리부서에 설정 변경 요청이 필요할 수 있으며 (요청 내용이) 해당 기업의 보안 정책과 상충될 소지가 있음.
• 사내망에서 Link를 타고 접속 시 외부망으로 나가는 트래픽에 대해 Proxy에서 HTTP 헤더 내용의 변조 등의 보안 정책이 있을 수 있음
• 접속 장소에 따라 Referrer 내용이 들어올 수도, 안들어올 수도 있음.
• AWS에 탑재된 웹사이트의 경우 AWS에서 HTTP 헤더의 내용을 변조하기 때문에 별도의 조치가 필요함 → 기획전이 이에 해당.
• 웹브라우저 정책이 점차 보안을 강화해나가는 추세이고 제각각이기 때문에, 향후 정책 변경에 대한 대응에 어려움이 있음.

→ Referrer 체크의 활용은 현재에는 제한적으로 사용가능하나,

각각의 웹브라우저 버전 및 정책, 요청 웹사이트 회사의 보안 정책과 인프라 환경 등에 대한 변수가 상존하기 때문에 (구동에 관한) 완전한 개런티 보장은 되지 않음.