이 페이지에서는 리퍼러 정책을 설정하고 수신 요청에 리퍼러를 사용하기 위한 몇 가지 권장사항을 간략히 설명합니다.
요약
- 예기치 않은 교차 출처 정보 유출로 인해 웹 사용자의 개인 정보가 손상됩니다. 보호 리퍼러 정책이 도움이 될 수 있습니다.
- 리퍼러 정책을
strict-origin-when-cross-origin
로 설정해 보세요. 리퍼러의 유용성을 대부분 유지하면서 서로 다른 출처에서 데이터 유출 위험을 줄입니다. - 교차 사이트 요청 위조 (CSRF) 방지를 위해 리퍼러를 사용하지 않습니다. 대신 CSRF 토큰을 사용하고 추가 보안 레이어로 다른 헤더를 사용하세요.
리퍼러 및 리퍼러 정책 101
HTTP 요청에는 요청이 생성된 원본 또는 웹페이지 URL을 나타내는 Referer
헤더(선택사항)가 포함될 수 있습니다. Referrer-Policy
헤더는 Referer
헤더에서 사용할 수 있는 데이터를 정의합니다.
다음 예에서 Referer
헤더에는 요청이 이루어진 site-one
페이지의 전체 URL이 포함되어 있습니다.
Referer
헤더는 다음과 같이 다양한 유형의 요청에 있을 수 있습니다.
- 사용자가 링크를 클릭하는 경우의 탐색 요청
- 브라우저가 페이지에 필요한 이미지, iframe, 스크립트, 기타 리소스를 요청하는 경우의 하위 리소스 요청
탐색 및 iframe의 경우 document.referrer
를 사용하여 JavaScript로 이 데이터에 액세스할 수도 있습니다.
Referer
값에서 많은 내용을 확인할 수 있습니다. 예를 들어 분석 서비스에서는
이를 사용하여 site-two.example
방문자의 50% 가 social-network.example
에서 유입되었다고
판단할 수 있습니다. 그러나 경로 및 쿼리 문자열을 포함한 전체 URL이 원본 간 Referer
에 전송되면 사용자 개인 정보 보호가 위협되고 보안 위험이 발생할 수 있습니다.
URL 1~5에는 개인 정보가 포함되며 때로는 민감한 정보나 식별 정보가 포함됩니다. 출처에 자동으로 이 정보를 노출하면 웹 사용자의 개인 정보 보호가 손상될 수 있습니다.
URL 6은 기능 URL입니다. 의도한 사용자 이외의 다른 사람이 이 이메일을 수신하면 악의적인 행위자가 이 사용자 계정을 제어할 수 있습니다.
사이트 요청에 제공되는 리퍼러 데이터를 제한하려면 리퍼러 정책을 설정하면 됩니다.
어떤 정책을 사용할 수 있으며 정책이 어떻게 다른가요?
8개의 정책 중 하나를 선택할 수 있습니다. 정책에 따라 Referer
헤더 및 document.referrer
에서 제공하는 데이터는 다음과 같을 수 있습니다.
- 데이터 없음 (
Referer
헤더 없음) - origin만
- 전체 URL: 원본, 경로, 쿼리 문자열
일부 정책은 컨텍스트(교차 출처 또는 동일 출처 요청), 요청 대상이 출처만큼 안전한지 또는 둘 다에 따라 다르게 동작하도록 설계되었습니다. 이는 자체 사이트 내 리퍼러의 다채로움을 유지하면서 출처 간 또는 보안 수준이 낮은 출처로 공유되는 정보의 양을 제한하는 데 유용합니다.
다음 표는 리퍼러 정책이 리퍼러 헤더 및 document.referrer
에서 사용할 수 있는 URL 데이터를 제한하는 방법을 보여줍니다.
정책 범위 | 정책 이름 | 리퍼러: 데이터 없음 | 리퍼러: 출처만 | 리퍼러: 전체 URL |
---|---|---|---|---|
요청 컨텍스트를 고려하지 않음 | no-referrer |
수표 | ||
origin |
수표 | |||
unsafe-url |
수표 | |||
보안 중심 | strict-origin |
HTTPS에서 HTTP로 요청 | HTTPS에서 HTTPS로 요청 또는 HTTP에서 HTTP로 요청 |
|
no-referrer-when-downgrade |
HTTPS에서 HTTP로 요청 | HTTPS에서 HTTPS로 요청 또는 HTTP에서 HTTP로 요청 |
||
개인 정보 보호 중심 | origin-when-cross-origin |
교차 출처 요청 | 동일 출처 요청 | |
same-origin |
교차 출처 요청 | 동일 출처 요청 | ||
개인 정보 보호 및 보안 중심 | strict-origin-when-cross-origin |
HTTPS에서 HTTP로 요청 | HTTPS에서 HTTPS로 또는 HTTP에서 HTTP로 교차 출처 요청 |
동일 출처 요청 |
MDN은 정책 및 동작 예시의 전체 목록을 제공합니다.
리퍼러 정책을 설정할 때 유의해야 할 사항은 다음과 같습니다.
- 스키마 (HTTPS와 HTTP)를 고려하는 모든 정책(
strict-origin
,no-referrer-when-downgrade
,strict-origin-when-cross-origin
)은 HTTP가 안전하지 않더라도 한 HTTP 출처에서 다른 HTTP 출처로의 요청을 HTTPS 출처에서 다른 HTTPS 출처로의 요청과 동일한 방식으로 취급합니다. 이러한 정책에서 중요한 것은 보안 다운그레이드가 발생했는지 여부입니다. 즉, HTTPS → HTTP 요청과 같이 요청이 암호화된 출처의 데이터를 암호화되지 않은 출처로 노출할 수 있는지 여부입니다. HTTP → HTTP 요청은 완전히 암호화되지 않으므로 다운그레이드가 없습니다. - 요청이 same-origin이면 스키마 (HTTPS 또는 HTTP)가 동일하므로 보안 다운그레이드가 적용되지 않습니다.
브라우저의 기본 리퍼러 정책
2021년 10월 기준
리퍼러 정책이 설정되지 않은 경우 브라우저에서 기본 정책을 사용합니다.
탐색자 | 기본 Referrer-Policy / 동작 |
---|---|
Chrome |
기본값은 strict-origin-when-cross-origin 입니다.
|
Firefox |
기본값은 strict-origin-when-cross-origin 입니다.버전 93부터 엄격한 추적 보호 및 시크릿 브라우징 사용자의 경우 덜 제한적인 리퍼러 정책 no-referrer-when-downgrade , origin-when-cross-origin , unsafe-url 가 크로스 사이트 요청에서 무시되므로 웹사이트의 정책에 관계없이 크로스 사이트 요청의 경우 리퍼러는 항상 잘립니다.
|
에지 |
기본값은 strict-origin-when-cross-origin 입니다.
|
Safari |
기본값은 strict-origin-when-cross-origin 와 비슷하지만 몇 가지 구체적인 차이점이 있습니다. 자세한 내용은
추적 방지 추적 방지를 참조하세요.
|
리퍼러 정책 설정 권장사항
사이트에 대한 리퍼러 정책을 설정하는 방법에는 여러 가지가 있습니다.
페이지, 요청, 요소별로 정책을 다르게 설정할 수 있습니다.
HTTP 헤더와 메타 요소는 모두 페이지 수준입니다. 요소의 유효 정책을 결정하는 우선순위는 다음과 같습니다.
- 요소 수준 정책
- 페이지 수준 정책
- 브라우저 기본값
예:
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
이미지는 no-referrer-when-downgrade
정책으로 요청되고, 이 페이지의 다른 모든 하위 리소스 요청은 strict-origin-when-cross-origin
정책을 따릅니다.
리퍼러 정책을 확인하는 방법
securityheaders.com을 사용하면 특정 사이트나 페이지에서 사용 중인 정책을 간편하게 확인할 수 있습니다.
Chrome, Edge 또는 Firefox의 개발자 도구를 사용하여 특정 요청에 사용된 리퍼러 정책을 확인할 수도 있습니다. 이 문서의 작성 시점을 기준으로 Safari는 Referrer-Policy
헤더를 표시하지 않고 전송된 Referer
만 표시합니다.
웹사이트에 어떤 정책을 설정해야 하나요?
strict-origin-when-cross-origin
또는 더 엄격한 등 개인 정보 보호 강화 정책을 명시적으로 설정하는 것이 좋습니다.
'명시적'인 이유는 무엇인가요?
리퍼러 정책을 설정하지 않으면 브라우저의 기본 정책이 사용됩니다. 실제로 웹사이트는 브라우저의 기본값을 따르는 경우가 많습니다. 그러나 이는 바람직하지 않은 이유는 다음과 같습니다.
- 브라우저마다 기본 정책이 다르므로 브라우저 기본값을 사용하면 사이트가 여러 브라우저에서 정상적으로 작동하지 않습니다.
- 브라우저는 더 엄격한 기본값(예:
strict-origin-when-cross-origin
)과 교차 출처 요청에 리퍼러 자르기와 같은 메커니즘을 채택하고 있습니다. 브라우저 기본값이 변경되기 전에 개인 정보 보호 강화 정책을 명시적으로 선택하면 제어 기능을 활용하고 필요에 따라 테스트를 실행할 수 있습니다.
strict-origin-when-cross-origin
(또는 더 엄격한) 기준을 적용하는 이유는 무엇인가요?
이를 위해서는 개인 정보 보호를 강화하며 유용한 정책이 필요합니다. '유용성'의 의미는 리퍼러에서 무엇을 원하는지에 따라 달라집니다.
- 보안: 웹사이트에서 HTTPS를 사용하는 경우 (사용하지 않는 경우 우선순위로 지정) 웹사이트 URL이 HTTPS가 아닌 요청에서 유출되는 것을 원하지 않습니다. 네트워크의 모든 사용자가 이러한 정보를 볼 수 있으므로 유출로 인해 사용자가 중간자 공격에 노출될 수 있습니다.
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
,strict-origin
정책이 이 문제를 해결합니다. - 개인 정보 보호 강화: 교차 출처 요청의 경우
no-referrer-when-downgrade
가 전체 URL을 공유하므로 개인 정보 보호 문제가 발생할 수 있습니다.strict-origin-when-cross-origin
및strict-origin
는 출처만 공유하고no-referrer
는 아무것도 공유하지 않습니다. 이렇게 하면strict-origin-when-cross-origin
,strict-origin
,no-referrer
가 개인 정보 보호 강화 옵션으로 남게 됩니다. - 유용성:
no-referrer
및strict-origin
는 동일한 출처 요청인 경우에도 전체 URL을 공유하지 않습니다. 전체 URL이 필요한 경우에는strict-origin-when-cross-origin
를 사용하는 것이 더 좋습니다.
이 모든 사항은 일반적으로 strict-origin-when-cross-origin
를 선택하는 것이 타당함을 의미합니다.
예시: strict-origin-when-cross-origin
정책 설정
index.html
:
<meta name="referrer" content="strict-origin-when-cross-origin" />
서버 측(예: Express)에서는 다음과 같이 사용할 수 있습니다.
const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));
strict-origin-when-cross-origin
(또는 더 엄격한)가 모든 사용 사례를 수용하지 못하면 어떻게 해야 하나요?
이 경우 점진적인 접근 방식을 취합니다. 즉, 웹사이트에 strict-origin-when-cross-origin
와 같은 보호 정책을 설정하고 필요한 경우 특정 요청 또는 HTML 요소에 더 많은 권한이 부여된 정책을 설정합니다.
예: 요소 수준 정책
index.html
:
<head>
<!-- document-level policy: strict-origin-when-cross-origin -->
<meta name="referrer" content="strict-origin-when-cross-origin" />
<head>
<body>
<!-- policy on this <a> element: no-referrer-when-downgrade -->
<a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
<body></body>
</body>
</head>
</head>
Safari/WebKit에서는 크로스 사이트 요청의 document.referrer
또는 Referer
헤더를 제한할 수 있습니다.
세부정보 보기
예시: 요청 수준 정책
script.js
:
fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});
그 밖에 무엇을 고려해야 하나요?
사용자, 팀, 회사의 판단에 따라 웹사이트 및 사용 사례에 따라 정책이 달라져야 합니다. 일부 URL에 식별 정보나 민감한 정보가 포함된 경우 보호 정책을 설정하세요.
수신 요청에 대한 권장사항
다음은 사이트에서 들어오는 요청의 리퍼러 URL을 사용하는 경우 취해야 할 조치에 대한 가이드라인입니다.
사용자 데이터 보호
Referer
에는 비공개, 개인 정보, 식별 데이터가 포함될 수 있으므로 이와 같이 취급해야 합니다.
수신되는 리퍼러는 {referer-can-change}을(를) 변경할 수 있습니다.
수신되는 교차 출처 요청에서 리퍼러를 사용하면 다음과 같은 몇 가지 제한사항이 있습니다.
- 요청 이미터의 구현을 제어할 수 없는 경우 수신하는
Referer
헤더 (및document.referrer
)에 대해 가정할 수 없습니다. 요청 이미터는 언제든지no-referrer
정책으로 전환하거나 , 더 일반적으로는 이전에 사용한 정책보다 더 엄격한 정책으로 전환할 수 있습니다. 즉, 전보다Referer
에서 수신하는 데이터가 적어집니다. - 브라우저에서 기본적으로 리퍼러 정책
strict-origin-when-cross-origin
을 사용하는 경우가 증가하고 있습니다. 즉, 발신자 사이트에 정책이 설정되지 않은 경우 수신되는 교차 출처 요청에서 전체 리퍼러 URL 대신 출처만 수신할 수 있습니다. - 브라우저에 따라
Referer
관리 방식이 변경될 수 있습니다. 예를 들어 일부 브라우저 개발자는 사용자 개인 정보 보호를 위해 항상 교차 출처 하위 리소스 요청에서 리퍼러를 잘라내기로 결정할 수 있습니다. Referer
헤더 (및document.referrer
)에는 필요한 것보다 더 많은 데이터가 포함될 수 있습니다. 예를 들어 요청이 교차 출처인지만 확인하려는 경우 전체 URL이 있을 수 있습니다.
Referer
의 대안
다음과 같은 경우 대안을 고려해야 할 수 있습니다.
- 사이트의 필수 기능은 수신되는 교차 출처 요청의 리퍼러 URL을 사용합니다.
- 사이트가 교차 출처 요청에서 필요한 리퍼러 URL의 일부를 더 이상 수신하지 않습니다. 이는 요청 이미터가 정책을 변경하거나 정책을 설정하지 않고 브라우저 기본값의 정책이 변경된 경우(예: Chrome 85) 발생합니다.
대안을 정의하려면 먼저 사용 중인 리퍼러의 어떤 부분을 분석하세요.
출처만 필요한 경우
- 페이지에 대한 최상위 액세스 권한이 있는 스크립트에서 리퍼러를 사용하는 경우
window.location.origin
를 사용할 수 있습니다. - 가능한 경우
Origin
및Sec-Fetch-Site
같은 헤더가Origin
를 제공하거나 요청이 교차 출처인지 여부를 설명합니다. 교차 출처가 정확히 필요할 수도 있습니다.
URL의 다른 요소 (경로, 쿼리 매개변수 등)가 필요한 경우
- 요청 매개변수를 사용하면 사용 사례를 처리할 수 있으므로 리퍼러를 파싱하지 않아도 됩니다.
- 페이지에 대한 최상위 액세스 권한이 있는 스크립트에서 리퍼러를 사용하는 경우
window.location.pathname
를 대안으로 사용할 수 있습니다. URL의 경로 섹션만 추출하여 인수로 전달하므로 URL 매개변수의 민감할 수 있는 정보는 전달되지 않습니다.
다음 대안을 사용할 수 없는 경우 다음 안내를 따르세요.
- 요청 이미터(예:
site-one.example
)가 일종의 구성에서 필요한 정보를 명시적으로 설정하도록 시스템을 변경할 수 있는지 확인합니다.- 장점:
site-one.example
사용자를 위해 보다 명시적이고 개인 정보가 보호되며 미래에도 경쟁력이 있습니다. - 단점: 개발자 측 또는 시스템 사용자에게 더 많은 작업이 필요할 수 있습니다.
- 장점:
- 요청을 생성하는 사이트에서
no-referrer-when-downgrade
의 요소별 또는 요청별 리퍼러 정책을 설정하는 데 동의할 수 있는지 확인합니다.- 단점:
site-one.example
사용자의 개인 정보 보호가 약화될 수 있으며 모든 브라우저에서 지원되지 않을 수 있습니다.
- 단점:
크로스 사이트 요청 위조 (CSRF) 방지
요청 이미터는 항상 no-referrer
정책을 설정하여 리퍼러를 전송하지 않기로 결정할 수 있으며, 악의적인 행위자가 리퍼러를 스푸핑할 수도 있습니다.
CSRF 토큰을 기본 보호 조치로 사용합니다. 추가 보호를 위해 SameSite를 사용하고 Referer
대신 Origin
(POST 및 CORS 요청에 사용 가능) 및 Sec-Fetch-Site
(사용 가능한 경우)와 같은 헤더를 사용합니다.
로깅 및 디버그
Referer
에 있을 수 있는 사용자의 개인 정보 또는 민감한 정보를 보호해야 합니다.
원본만 사용하는 경우 대안으로 Origin
헤더를 사용할 수 있는지 확인합니다. 이렇게 하면 리퍼러를 파싱할 필요 없이 더 간단한 방식으로 디버깅 목적으로 필요한 정보를 얻을 수 있습니다.
지불
결제 제공업체는 보안 확인을 위해 수신 요청의 Referer
헤더를 사용할 수 있습니다.
예를 들면 다음과 같습니다.
- 사용자가
online-shop.example/cart/checkout
에서 구매 버튼을 클릭합니다. online-shop.example
는payment-provider.example
로 리디렉션되어 트랜잭션을 관리합니다.payment-provider.example
는 이 요청의Referer
를 판매자가 설정한 허용되는Referer
값 목록과 대조합니다. 목록의 항목과 일치하지 않으면payment-provider.example
는 요청을 거부합니다. 일치하는 경우 사용자는 거래를 진행할 수 있습니다.
결제 흐름 보안 확인을 위한 권장사항
결제 시스템 공급자는 Referer
를 일부 공격에 대한 기본 검사로 사용할 수 있습니다. 하지만 Referer
헤더 자체는 신뢰할 수 있는 확인 기반이 아닙니다. 요청 사이트는 합법적인 판매자인지 여부와 관계없이 결제 시스템 공급자가 Referer
정보를 사용할 수 없도록 하는 no-referrer
정책을 설정할 수 있습니다.
Referer
를 확인하면 결제 서비스 제공업체가 no-referrer
정책을 설정하지 않은 단순한 공격자를 포착하는 데 도움이 될 수 있습니다. Referer
를 첫 번째 검사로 사용하는 경우:
Referer
가 항상 있을 것으로 기대하지 마세요. 데이터 세트가 있는 경우 포함할 수 있는 최소 데이터(원본)와 대조해 확인합니다.- 허용되는
Referer
값의 목록을 설정할 때는 경로 없이 출처만 포함해야 합니다. - 예를 들어
online-shop.example
에 허용되는Referer
값은online-shop.example/cart/checkout
가 아닌online-shop.example
여야 합니다.Referer
를 전혀 예상하지 않거나 요청하는 사이트의 출처만 있는Referer
값을 기대하면 판매자의Referrer-Policy
를 가정하여 발생할 수 있는 오류를 방지할 수 있습니다.
- 허용되는
Referer
가 없거나 이 항목이 있고 기본Referer
출처 확인에 성공하면 보다 안정적인 다른 확인 방법으로 이동할 수 있습니다.
결제를 보다 안정적으로 확인하려면 요청자가 고유 키를 사용하여 요청 매개변수를 해싱할 수 있습니다. 그러면 결제 시스템 공급자가 개발자 측에서 동일한 해시를 계산하고 계산과 일치하는 경우에만 요청을 수락할 수 있습니다.
리퍼러 정책이 없는 HTTP 판매자 사이트가 HTTPS 결제 시스템 공급자로 리디렉션되면 Referer
는 어떻게 되나요?
HTTPS 결제 시스템 공급자에 대한 요청에는 Referer
가 표시되지 않습니다. 웹사이트에 설정된 정책이 없는 경우 대부분의 브라우저가 기본적으로 strict-origin-when-cross-origin
또는 no-referrer-when-downgrade
를 사용하기 때문입니다.
Chrome에서 새 기본 정책을 변경해도 이 동작은 변경되지 않습니다.
결론
보호되는 리퍼러 정책은 사용자의 개인 정보를 더 안전하게 보호하는 데 좋은 방법입니다.
사용자를 보호하는 다양한 기술에 관한 자세한 내용은 안전 및 보안 컬렉션을 참고하세요.
자료
- '동일 사이트' 및 '동일 출처' 이해하기
- 새로운 보안 헤더: 리퍼러 정책(2017)
- MDN의 리퍼러 정책
- 참조 헤더: MDN의 개인 정보 보호 및 보안 문제
- Chrome 변경사항: 구현할 인텐트 깜박임
- Chrome 변경사항: 깜박이는 인텐트 전송
- Chrome 변경: 상태 입력
- Chrome 변경사항: 85 베타 블로그 게시물
- 리퍼러 GitHub 스레드 자르기: 브라우저별 기능
- 리퍼러 정책 사양
모든 검토자(특히 카우스투바 고빈드, 데이비드 반 클레브, 마이크 웨스트, 샘 더튼, 로완 메어우드, 잭, 케이스 바스크스)에게 기여하고 의견을 주신 데 대해 많은 감사를 드립니다.