프로그래밍/HTML, Javascript, CSS

Referrer-Policy는 무엇이고 어떤 값을 써야 할까? strict-origin-when-cross-origin 기준 정리

포도알77 2026. 5. 10. 10:12
반응형

Referrer-Policy는 무엇이고 어떤 값을 써야 할까? strict-origin-when-cross-origin 기준 정리

Referrer-Policy는 브라우저가 요청을 보낼 때 Referer 헤더에 어느 범위의 이전 URL 정보를 담을지 정하는 HTTP 응답 헤더다. 2026년 5월 10일 기준 MDN과 W3C Referrer Policy 문서를 보면, 이 헤더는 전체 URL을 보낼지, origin만 보낼지, 아예 보내지 않을지를 정책 값으로 제어한다.

실무에서는 분석 도구, 외부 스크립트, CDN, 결제 이동, 이미지 핫링크 같은 상황에서 이 값이 직접 영향을 준다. 이 글은 공식 문서를 기준으로 각 정책의 차이와 현재 기본값, 그리고 어떤 상황에서 어떤 값을 검토해야 하는지를 객관적인 사실 위주로 정리한다.

Referrer-Policy는 정확히 무엇을 제어할까?

MDN은 Referrer-Policy를 요청에 포함되는 referrer 정보의 양을 제어하는 응답 헤더로 설명한다. 여기서 실제 요청 헤더 이름은 Referer인데, 헤더 이름은 역사적인 이유로 철자가 잘못된 상태이고 정책 이름은 올바른 Referrer를 쓴다.

Referer 헤더에는 문서의 전체 URL, origin만 남긴 값, 또는 아무 값도 들어가지 않을 수 있다. 다만 문서와 표준은 URL fragment와 사용자 이름, 비밀번호 정보는 referrer에 포함되지 않도록 정의한다.

2026년 기준 기본값은 무엇인가?

MDN은 2026년 5월 10일 확인 기준, 정책을 따로 지정하지 않았거나 잘못된 값을 넣은 경우 기본값이 strict-origin-when-cross-origin라고 설명한다. MDN은 이전 기본값이 no-referrer-when-downgrade였고, 현재 기본값 변경은 2020년 11월 스펙 개정과 연결된다고 적고 있다.

이 기본값에서는 same-origin 요청에는 전체 URL이 전달될 수 있고, HTTPS에서 HTTPS로 가는 cross-origin 요청에는 origin만 전달되며, HTTPS에서 HTTP로 내려가는 요청에는 Referer가 전송되지 않는다.

정책 값은 어떻게 나뉠까?

W3C Referrer Policy와 MDN이 공통으로 설명하는 주요 값은 다음과 같다.

  • no-referrer: 어떤 요청에도 referrer를 보내지 않는다.
  • same-origin: same-origin 요청에만 전체 URL을 보낸다.
  • origin: same-origin과 cross-origin 모두 origin만 보낸다.
  • origin-when-cross-origin: same-origin에는 전체 URL, cross-origin에는 origin만 보낸다.
  • strict-origin: 보안 수준이 유지될 때만 origin을 보내고 HTTPS에서 HTTP로는 보내지 않는다.
  • strict-origin-when-cross-origin: same-origin에는 전체 URL, 보안 수준이 유지되는 cross-origin에는 origin만 보내며 HTTPS에서 HTTP로는 보내지 않는다.
  • unsafe-url: 어디로 가든 origin, path, query까지 보낼 수 있다.

왜 기본값이 strict-origin-when-cross-origin일까?

이 질문에 대한 직접적인 설계 의도는 표준의 privacy와 security 설명에서 읽을 수 있다. 전체 URL referrer는 분석과 디버깅에는 유용하지만, path나 query string 안에 민감한 식별자나 검색어가 들어 있으면 외부 origin으로 정보가 흘러갈 수 있다.

strict-origin-when-cross-origin는 same-origin에서는 상세 URL을 유지해 내부 분석과 라우팅 진단에 도움이 되면서, cross-origin에서는 origin만 남기고 HTTPS에서 HTTP로 내려갈 때는 referrer를 막는다. 즉 기본 동작만으로도 분석 편의와 정보 최소화 사이의 균형을 맞추려는 정책이라고 해석할 수 있다.

어떤 값이 언제 문제가 될까?

1. unsafe-url은 왜 주의해야 할까?

MDN은 unsafe-url이 HTTPS URL의 path와 query 같은 잠재적으로 민감한 정보를 안전하지 않은 origin으로도 보낼 수 있다고 경고한다. 로그인 후 이동 경로, 검색어, 내부 문서 경로를 URL에 담는 서비스라면 특히 검토가 필요하다.

2. no-referrer는 언제 과할 수 있을까?

모든 요청에서 referrer를 지우면 외부 분석 도구, 결제 전환 분석, 파트너 유입 분석, 일부 CSRF 방어 보조 로그가 기대하는 정보가 사라질 수 있다. 보안상 가장 보수적이지만, 운영 관측성은 줄어든다.

3. originstrict-origin의 차이는 무엇일까?

둘 다 path와 query를 보내지 않는다는 점은 같지만, origin은 HTTPS에서 HTTP로 가더라도 origin을 보낼 수 있다. 반면 strict-origin은 보안 수준이 낮아지는 이동에서는 referrer를 보내지 않는다.

보통 무엇을 기준으로 고르면 될까?

아래 기준은 공식 문서에 나온 동작 차이에서 바로 따라오는 선택 기준이다.

  • 외부로 path와 query를 보내고 싶지 않지만 내부 same-origin 분석은 유지하고 싶다면 strict-origin-when-cross-origin이 기준점이 된다.
  • cross-origin 요청에도 origin만 남기고, HTTPS에서 HTTP로의 유출은 막고 싶다면 strict-origin 또는 기본값인 strict-origin-when-cross-origin를 먼저 검토할 수 있다.
  • 아예 어떤 referrer도 남기고 싶지 않다면 no-referrer가 가장 보수적이다.
  • 외부 분석이나 연동 때문에 전체 URL 전달이 꼭 필요하다면 unsafe-url 또는 더 완화된 정책을 검토할 수 있지만, URL 설계와 민감정보 포함 여부를 먼저 확인해야 한다.

위 기준 중 마지막 항목은 정책 동작을 바탕으로 한 운영 판단이다. 실제 선택은 서비스의 URL 구조, 외부 연동, 개인정보 정책에 따라 달라진다.

헤더 말고 HTML에서도 지정할 수 있을까?

가능하다. MDN은 문서 전체에 대해 <meta name="referrer" ...>로 정책을 줄 수 있고, 개별 요청에는 referrerpolicy 속성을 <a>, <img>, <script>, <iframe>, <link> 등에 붙일 수 있다고 설명한다.

또 링크에는 rel="noreferrer"를 쓸 수도 있다. 이 값은 대시 없는 noreferrer이고, 메타 태그의 no-referrer와 표기가 다르다는 점을 MDN이 별도로 경고한다.

CSS 요청에도 영향이 있을까?

있다. MDN은 외부 CSS 스타일시트가 가져오는 리소스도 referrer policy의 영향을 받는다고 설명한다. 외부 CSS 파일은 기본 정책인 strict-origin-when-cross-origin를 따르며, 해당 CSS 응답에 별도 Referrer-Policy 헤더가 있으면 그 값이 우선할 수 있다.

반면 문서 안의 <style> 요소나 style 속성에서 발생하는 요청은 소유 문서의 정책을 따른다.

FAQ

Q. 기본값이면 대부분 충분할까?

공식 문서 기준으로 기본값은 strict-origin-when-cross-origin다. same-origin 상세 URL은 유지하면서 cross-origin 정보 노출을 줄이는 동작이므로, 별도 요구사항이 없는 일반 웹 서비스에서는 우선 비교 기준으로 삼기 쉽다. 다만 이것이 모든 서비스의 최적값이라는 뜻은 아니다.

Q. HTTPS에서 HTTP로 이동할 때 왜 referrer가 비어 있을 수 있을까?

strict-originstrict-origin-when-cross-origin는 HTTPS에서 HTTP처럼 보안 수준이 낮아지는 이동에 대해 referrer 전송을 막기 때문이다. MDN과 W3C 문서 모두 이 동작을 명시한다.

Q. 구형 브라우저 호환용 fallback도 줄 수 있을까?

가능하다. MDN은 쉼표로 구분한 정책 목록을 예시로 들며, 지원하지 않는 브라우저에서는 앞선 fallback을 쓰고 지원하는 브라우저에서는 마지막 정책을 사용할 수 있다고 설명한다.

정리

Referrer-Policy는 단순한 보안 헤더가 아니라, 개인정보 노출 범위와 분석 가능성을 동시에 조절하는 설정이다. 2026년 5월 10일 기준 공식 문서상 기본값은 strict-origin-when-cross-origin이며, 이는 same-origin 상세 정보 유지와 cross-origin 정보 최소화 사이의 절충안에 가깝다.

운영 중인 서비스에서 URL path나 query에 민감한 값이 들어갈 수 있다면, 현재 정책이 무엇인지 먼저 확인하는 편이 안전하다. 반대로 외부 분석 정확도가 중요하다면 정책을 완화했을 때 어떤 URL 정보가 실제로 외부로 나가는지 함께 점검해야 한다.

참고 자료

728x90
페이스북으로 공유카카오톡으로 공유카카오스토리로 공유트위터로 공유URL 복사