Referrer-Policy 추천기

사이트 유형에 맞는 Referrer-Policy 값을 추천하고 각 값의 동작을 비교합니다.

Referrer-Policy 응답 헤더는 사용자가 링크를 클릭하거나 리소스를 불러올 때 브라우저가 Referer 헤더로 어디까지 보내는지를 제어합니다. 너무 많이 보내면 전체 URL(쿼리스트링·세션 토큰 포함)이 외부 사이트로 새어 나갈 수 있고, 너무 적게 보내면 유입 분석이나 일부 인증 흐름이 깨질 수 있습니다.

이 도구는 사이트 성격(일반·개인정보 민감·분석/광고 의존)만 고르면 권장 Referrer-Policy 값을 바로 추천하고, 8가지 정책 값의 동작 차이를 한눈에 비교해 줍니다. 전체 보안 헤더 점검은 보안 헤더 점검, 함께 자주 설정하는 콘텐츠 보안 정책은 CSP 생성기를 참고하세요.

사이트 성격을 선택하세요

권장 Referrer-Policy

strict-origin-when-cross-origin

응답 헤더	Referrer-Policy: strict-origin-when-cross-origin
추천 이유	최신 브라우저 기본값과 동일합니다. 같은 출처에는 전체 URL, 다른 출처에는 출처(origin)만 보내고 다운그레이드 시 아무것도 보내지 않아 안전과 호환성의 균형이 가장 좋습니다.

8가지 정책 값 비교

값	동작
no-referrer	어떤 경우에도 Referer를 전혀 보내지 않음
no-referrer-when-downgrade	다운그레이드(HTTPS→HTTP)가 아니면 전체 URL을 보냄 (과거 기본값)
origin	항상 출처(scheme+host+port)만 보냄
origin-when-cross-origin	같은 출처엔 전체 URL, 다른 출처엔 출처만
same-origin	같은 출처엔 전체 URL, 다른 출처엔 전혀 안 보냄
strict-origin	출처만 보내되 다운그레이드 시 아무것도 안 보냄
strict-origin-when-cross-origin	같은 출처엔 전체 URL, 다른 출처엔 출처만, 다운그레이드 시 아무것도 (현재 기본값)
unsafe-url비권장	다운그레이드 포함 항상 전체 URL을 보냄 — 위험, 비권장

왜 strict-origin-when-cross-origin이 기본인가

최신 브라우저는 정책 미설정 시 strict-origin-when-cross-origin을 기본값으로 사용합니다. 같은 출처에는 전체 URL을, 다른 출처에는 출처(origin)만 보내고, HTTPS→HTTP 다운그레이드에서는 아무것도 보내지 않습니다. 분석 도구가 유입 도메인을 인식할 수 있을 만큼은 보내면서, 경로·쿼리스트링 유출은 막는 균형점입니다.

일반 사이트: strict-origin-when-cross-origin (사실상 기본값)
개인정보 민감: no-referrer 또는 same-origin
분석·광고 의존: strict-origin-when-cross-origin (출처는 유지)

피해야 할 값

unsafe-url은 다운그레이드 상황에서도 항상 전체 URL을 보냅니다. 쿼리스트링에 들어간 토큰·이메일·검색어가 제3자에게 그대로 전달될 수 있어 거의 모든 경우에 권장하지 않습니다. no-referrer-when-downgrade는 과거의 관대한 기본값으로, 교차 출처에 전체 URL을 보내므로 명시적으로 선택하지 않는 편이 좋습니다.

적용 방법

서버 응답 헤더로 내려주는 것이 가장 확실합니다. nginx는 add_header Referrer-Policy "strict-origin-when-cross-origin" always;, 메타 태그로는 <meta name="referrer" content="strict-origin-when-cross-origin"> 형태로 적용할 수 있습니다. 헤더와 메타 태그가 동시에 있으면 일반적으로 헤더가 우선합니다.

8가지 정책 값 전체 비교표

아래 표는 각 값이 같은 출처·다른 출처·HTTPS→HTTP 다운그레이드세 가지 상황에서 Referer에 무엇을 담는지 정리한 것입니다. "전체 URL"은 경로·쿼리스트링까지, "출처만"은 https://example.com처럼 스킴+호스트+포트까지, "없음"은 헤더 자체를 보내지 않음을 뜻합니다.

정책 값	같은 출처	다른 출처	다운그레이드
`no-referrer`	없음	없음	없음
`no-referrer-when-downgrade`	전체 URL	전체 URL	없음
`origin`	출처만	출처만	출처만
`origin-when-cross-origin`	전체 URL	출처만	출처만
`same-origin`	전체 URL	없음	없음
`strict-origin`	출처만	출처만	없음
`strict-origin-when-cross-origin` (기본)	전체 URL	출처만	없음
`unsafe-url`	전체 URL	전체 URL	전체 URL

실제 예시로 보기

https://shop.example.com/order?token=abc123&email=kim@test.com 페이지에서 외부 결제사 https://pg.partner.com으로 이동한다고 가정합시다. 같은 HTTPS이므로 다운그레이드는 아니고, 호스트가 다르므로 "다른 출처"에 해당합니다.

unsafe-url → Referer: https://shop.example.com/order?token=abc123&email=kim@test.com (토큰·이메일 그대로 노출)
no-referrer-when-downgrade → 위와 동일하게 전체 URL 노출 (HTTPS→HTTPS라 다운그레이드 보호가 작동하지 않음)
strict-origin-when-cross-origin → Referer: https://shop.example.com (출처만, 토큰 보호)
no-referrer → Referer 헤더 없음

흔한 실수 / 함정

가장 흔한 오해는 no-referrer-when-downgrade가 "안전한 값"이라는 착각입니다. 이름의 "downgrade"는 오직 HTTPS→HTTP 강등만 막아 줄 뿐, 요즘처럼 출발지·도착지가 모두 HTTPS인 교차 출처 이동에서는 쿼리스트링까지 포함한 전체 URL을 그대로 보냅니다. 즉 현대 웹에서는 사실상 unsafe-url과 다를 바 없는 노출이 일어나므로, "출처만 보내고 싶다"면 반드시 strict-origin-when-cross-origin또는 strict-origin을 선택해야 합니다.

자주 묻는 질문

Referer 헤더 철자가 원래 referrer 아닌가요?

맞습니다. HTTP 헤더 이름은 초기 명세의 오타 때문에 'Referer'로 굳어졌고, 정책 헤더와 자바스크립트 API는 올바른 철자인 'Referrer'를 씁니다. 즉 헤더는 Referer, 정책은 Referrer-Policy로 철자가 다릅니다.

개인정보 민감 사이트는 no-referrer와 same-origin 중 무엇을 쓸까요?

외부로 출처조차 보내고 싶지 않다면 no-referrer가 가장 안전합니다. 다만 자기 도메인 내부 페이지 간 유입 분석이 필요하면 same-origin이 적절합니다. same-origin은 같은 출처에는 전체 URL을 보내고 외부에는 아무것도 보내지 않습니다.

분석/광고를 쓰는데 referrer를 막으면 어떻게 되나요?

no-referrer를 쓰면 유입 채널이 'direct'로 뭉뚱그려져 캠페인 성과 분석이 어려워집니다. strict-origin-when-cross-origin은 경로·쿼리는 숨기되 출처 도메인은 유지하므로 분석 도구가 유입 도메인을 인식할 수 있습니다.

메타 태그와 응답 헤더 중 무엇이 우선인가요?

둘 다 설정된 경우 일반적으로 HTTP 응답 헤더가 우선합니다. 또한 헤더는 첫 요청부터 적용되지만 메타 태그는 HTML이 파싱된 뒤 적용되므로, 가능하면 서버 응답 헤더로 설정하는 것을 권장합니다.

입력한 값이 서버로 전송되나요?

아니요. 모든 추천 계산은 브라우저 안에서만 처리되며, 선택한 사이트 성격이나 생성된 헤더 문자열은 어디로도 전송되거나 저장되지 않습니다.