Referrer-Policy 설정으로 내 URL 정보 새는 것 막기

1. 왜 Referrer-Policy 설정이 필요한가

웹사이트를 운영하다 보면, 생각보다 많은 정보가 외부로 함께 전달되는 경우가 있습니다. 특히 페이지 이동이나 외부 링크 클릭 과정에서 URL 일부가 다른 사이트로 넘어가면, 의도하지 않은 정보 노출로 이어질 수 있습니다. 이런 문제를 줄이기 위해 자주 확인하는 항목이 바로 Referrer-Policy입니다.
검색에서 리퍼러정보보호나 개인정보보호를 함께 찾는 이유도 여기에 있습니다. 단순히 접속 기록을 숨기는 문제가 아니라, 서비스 구조상 어디까지 정보를 노출해도 되는지 점검하려는 목적이 큽니다.
이 글에서는 Referrer-Policy가 무엇인지, 어떤 정보가 새어 나갈 수 있는지, 그리고 왜 보안헤더 설정의 일부로 함께 관리해야 하는지 알아보겠습니다.

2. Referrer-Policy가 하는 역할

1) 리퍼러 정보가 무엇인지 이해하기

리퍼러(referrer)는 사용자가 어떤 페이지에서 어떤 페이지로 이동했는지 알려주는 정보입니다. 예를 들어 A 페이지에서 B 페이지로 이동하면, B 페이지는 A 페이지의 주소 일부를 참고할 수 있습니다.
문제는 이 정보에 경로, 쿼리스트링, 때로는 민감한 파라미터가 포함될 수 있다는 점입니다. 그래서 Referrer-Policy를 설정해 전달 범위를 조절하는 것이 중요합니다.

2) 어떤 상황에서 정보가 새어 나갈 수 있는지

보통 외부 광고 링크, 분석 도구, 제3자 이미지나 스크립트 호출, 다른 도메인으로의 이동에서 리퍼러가 전달될 수 있습니다. 만약 URL에 사용자 식별값, 내부 페이지 구조, 검색 조건 같은 정보가 들어 있다면 의도치 않은 노출이 발생할 수 있습니다.
이런 이유로 리퍼러정보보호는 단순한 설정 문제가 아니라 운영 정책에 가까운 성격을 가집니다.

3) 개인정보보호 관점에서 왜 중요한지

URL에는 이름이나 이메일 같은 직접적인 개인정보가 들어가지 않더라도, 사용자 행동 패턴이나 내부 경로가 드러날 수 있습니다. 예를 들어 결제 흐름, 회원 전용 페이지, 상담 신청 경로가 외부에 남으면 서비스 운영 정보가 추측될 수 있습니다.
따라서 개인정보보호 관점에서는 최소한의 정보만 전달하도록 설계하는 것이 바람직합니다.

3. Referrer-Policy 설정에서 자주 보는 값

1) no-referrer

리퍼러 정보를 아예 보내지 않는 방식입니다. 가장 보수적인 설정으로, 외부에 URL 정보가 전달되는 것을 최소화하고 싶을 때 사용합니다.
다만 모든 경우에 이 값이 적합한 것은 아니며, 서비스 특성상 유입 경로 분석이 필요한 경우에는 영향이 있을 수 있습니다.

2) strict-origin-when-cross-origin

현재 많이 사용되는 방식 중 하나로, 같은 출처에서는 더 많은 정보를 유지하고 교차 출처로 이동할 때는 제한적으로 전달합니다.
실무에서는 과도하게 차단하지 않으면서도 보안헤더로서 균형을 잡고 싶을 때 검토하는 경우가 많습니다.

3) origin

도메인 수준의 정보만 전달하고 상세 경로는 숨기는 방식입니다.
예를 들어 전체 URL이 아니라 사이트의 기본 출처만 노출되도록 하여 리퍼러정보보호 수준을 높일 수 있습니다.

4. 함께 점검하면 좋은 보안헤더 항목

1) HTTPS와 인증서 상태

Referrer-Policy만 설정한다고 보안이 완성되는 것은 아닙니다. 먼저 HTTPS 적용 여부와 인증서 정상 작동을 확인해야 합니다. 암호화 통신이 제대로 되어 있어야 URL 정보 노출 위험도 함께 줄어듭니다.
기본적인 연결 상태가 불안정하면 다른 보안헤더도 기대한 대로 동작하지 않을 수 있습니다.

2) CORS와 쿠키 정책

교차 출처 요청이 많다면 CORS 설정도 함께 봐야 합니다. 쿠키가 어디서, 어떤 조건으로 전송되는지에 따라 민감한 정보가 예상보다 넓게 공유될 수 있기 때문입니다.
이 영역은 Referrer-Policy와 직접 같지는 않지만, 전체적인 개인정보보호 수준을 좌우한다는 점에서 같이 점검하는 편이 좋습니다.

3) Mixed Content와 보안 취약점

HTTPS 페이지 안에서 HTTP 리소스를 불러오면 Mixed Content 문제가 생길 수 있습니다. 이런 경우 브라우저 경고가 발생하거나 일부 기능이 막힐 수 있습니다.
또한 XSS처럼 브라우저에서 실제로 발생하는 취약점은 리퍼러 정보보다 더 직접적인 위험으로 이어질 수 있어, 기본 점검이 중요합니다.

5. 실제로 점검할 때 확인해야 할 부분

1) 현재 설정값이 무엇인지

운영 중인 사이트에서 Referrer-Policy가 어떤 값으로 적용되어 있는지 먼저 확인해야 합니다. 설정이 아예 없으면 브라우저 기본 동작에 맡겨질 수 있어, 의도와 다르게 정보가 전달될 수 있습니다.
이런 초기 점검은 복잡한 보안 도구 없이도 빠르게 확인할 수 있는 항목에 속합니다.

2) 외부 연결이 많은 페이지인지

광고, 분석, 고객지원, 결제 등 외부 서비스와 연결되는 페이지가 많다면 리퍼러 전달 범위를 더 신경 써야 합니다.
특히 URL에 실험용 파라미터나 내부 식별자가 포함되는 경우, Referrer-Policy 설정이 사실상 정보 노출을 줄이는 기본 장치가 됩니다.

3) 서비스 목적과 균형이 맞는지

너무 강하게 차단하면 분석이나 유입 추적이 어려워질 수 있고, 너무 느슨하면 정보 노출 범위가 넓어집니다.
따라서 개인정보보호와 운영 편의성 사이에서 어떤 수준이 적절한지 결정하는 과정이 필요합니다.

6. URL 입력만으로 기본 상태를 점검하는 방식의 장점

1) 설정 지식이 많지 않아도 빠르게 확인 가능

보안 설정은 항목이 많고 용어도 복잡해서, 처음부터 모든 내용을 직접 확인하기 어렵습니다. URL을 입력하면 기본적인 보안 상태를 빠르게 점검할 수 있는 도구는 이런 부담을 줄여줍니다.
특히 보안헤더처럼 눈으로 바로 보이지 않는 항목을 손쉽게 확인할 때 유용합니다.

2) 실제 서비스 기준으로 확인 가능

개발환경과 실제 운영 환경은 다를 수 있습니다. 같은 사이트라도 배포 상태, CDN 설정, 외부 스크립트 추가 여부에 따라 결과가 달라질 수 있기 때문입니다.
그래서 실제 URL 기준으로 체크하는 방식은 리퍼러정보보호가 운영 중에 어떻게 적용되는지 보기 좋습니다.

3) 반복 점검에 적합한 편임

기본적인 보안은 한 번 설정하고 끝나는 경우보다, 배포와 수정이 반복될 때 다시 점검해야 하는 경우가 많습니다.
이런 상황에서는 URL만 넣어 빠르게 확인하는 방식이 프로젝트별 기본 점검으로 활용되기 쉽습니다.

7. 정리: 어떤 경우에 Referrer-Policy를 챙겨야 할까

1) 외부 링크가 많거나 URL에 정보가 포함되는 경우

이동 경로가 많은 사이트, 파라미터가 자주 붙는 서비스, 외부 분석 도구를 많이 쓰는 환경이라면 Referrer-Policy 설정을 다시 보는 것이 좋습니다.
이런 경우는 리퍼러정보보호와 개인정보보호를 함께 고려해야 하는 대표적인 상황입니다.

2) 보안헤더 전반을 함께 점검하고 싶은 경우

Referrer-Policy는 단독으로 보기보다 HTTPS, CORS, 쿠키, Mixed Content 같은 항목과 함께 봐야 실제 의미가 있습니다.
즉, 특정 한 가지 기능이 아니라 전체 보안헤더 상태를 정리하는 과정에서 함께 확인하는 편이 더 실용적입니다.

3) 직접 하나씩 확인하기 번거로운 경우

서버 설정이나 브라우저 동작을 직접 따라가며 점검하는 것이 익숙하지 않다면, URL 입력만으로 기본 상태를 확인하는 도구가 도움이 될 수 있습니다.
직접 전화나 문의로 하나씩 확인하는 방식과 비교하면, 먼저 스스로 점검해 보고 필요한 부분만 추가 확인할 수 있다는 점이 차이입니다. 결국 Referrer-Policy 설정은 URL 정보가 어디까지 전달되는지 관리하는 출발점이며, 기본적인 개인정보보호와 리퍼러정보보호를 위해 운영 중 한 번씩 점검해두면 유용합니다.