이 페이지는 Cloud Translation API를 통해 번역되었습니다.

리퍼러 및 리퍼러 정책 권장사항

Maud Nalpas

이 페이지에서는 리퍼러 정책을 설정하고 수신 요청에 리퍼러를 사용하기 위한 몇 가지 권장사항을 간략히 설명합니다.

요약

예기치 않은 교차 출처 정보 유출로 인해 웹 사용자의 개인 정보가 손상됩니다. 보호 리퍼러 정책이 도움이 될 수 있습니다.
리퍼러 정책을 strict-origin-when-cross-origin로 설정해 보세요. 리퍼러의 유용성을 대부분 유지하면서 서로 다른 출처에서 데이터 유출 위험을 줄입니다.
교차 사이트 요청 위조 (CSRF) 방지를 위해 리퍼러를 사용하지 않습니다. 대신 CSRF 토큰을 사용하고 추가 보안 레이어로 다른 헤더를 사용하세요.

리퍼러 및 리퍼러 정책 101

HTTP 요청에는 요청이 생성된 원본 또는 웹페이지 URL을 나타내는 Referer 헤더(선택사항)가 포함될 수 있습니다. Referrer-Policy 헤더는 Referer 헤더에서 사용할 수 있는 데이터를 정의합니다.

다음 예에서 Referer 헤더에는 요청이 이루어진 site-one 페이지의 전체 URL이 포함되어 있습니다.

리퍼러 헤더가 포함된 HTTP 요청입니다. — 리퍼러 헤더가 있는 HTTP 요청입니다.

Referer 헤더는 다음과 같이 다양한 유형의 요청에 있을 수 있습니다.

사용자가 링크를 클릭하는 경우의 탐색 요청
브라우저가 페이지에 필요한 이미지, iframe, 스크립트, 기타 리소스를 요청하는 경우의 하위 리소스 요청

탐색 및 iframe의 경우 document.referrer를 사용하여 JavaScript로 이 데이터에 액세스할 수도 있습니다.

Referer 값에서 많은 내용을 확인할 수 있습니다. 예를 들어 분석 서비스에서는 이를 사용하여 site-two.example 방문자의 50% 가 social-network.example에서 유입되었다고 판단할 수 있습니다. 그러나 경로 및 쿼리 문자열을 포함한 전체 URL이 원본 간 Referer에 전송되면 사용자 개인 정보 보호가 위협되고 보안 위험이 발생할 수 있습니다.

다양한 개인 정보 보호 및 보안 위험에 매핑된 경로가 있는 URL — 전체 URL을 사용하면 사용자 개인 정보 보호 및 보안에 영향을 미칠 수 있습니다.

URL 1~5에는 개인 정보가 포함되며 때로는 민감한 정보나 식별 정보가 포함됩니다. 출처에 자동으로 이 정보를 노출하면 웹 사용자의 개인 정보 보호가 손상될 수 있습니다.

URL 6은 기능 URL입니다. 의도한 사용자 이외의 다른 사람이 이 이메일을 수신하면 악의적인 행위자가 이 사용자 계정을 제어할 수 있습니다.

사이트 요청에 제공되는 리퍼러 데이터를 제한하려면 리퍼러 정책을 설정하면 됩니다.

어떤 정책을 사용할 수 있으며 정책이 어떻게 다른가요?

8개의 정책 중 하나를 선택할 수 있습니다. 정책에 따라 Referer 헤더 및 document.referrer에서 제공하는 데이터는 다음과 같을 수 있습니다.

데이터 없음 (Referer 헤더 없음)
origin만
전체 URL: 원본, 경로, 쿼리 문자열

리퍼러 헤더 및 document.referrer에
포함될 수 있는 데이터입니다. — 리퍼러 데이터의 예

일부 정책은 컨텍스트(교차 출처 또는 동일 출처 요청), 요청 대상이 출처만큼 안전한지 또는 둘 다에 따라 다르게 동작하도록 설계되었습니다. 이는 자체 사이트 내 리퍼러의 다채로움을 유지하면서 출처 간 또는 보안 수준이 낮은 출처로 공유되는 정보의 양을 제한하는 데 유용합니다.

다음 표는 리퍼러 정책이 리퍼러 헤더 및 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`와 비슷하지만 몇 가지 구체적인 차이점이 있습니다. 자세한 내용은 추적 방지 추적 방지를 참조하세요.

리퍼러 정책 설정 권장사항

목표: 개인 정보 보호 강화 정책을 명시적으로 설정합니다(예: strict-origin-when-cross-origin 또는 더 엄격한).

사이트에 대한 리퍼러 정책을 설정하는 방법에는 여러 가지가 있습니다.

HTTP 헤더로
HTML
요청별로 JavaScript에서 가져옴

페이지, 요청, 요소별로 정책을 다르게 설정할 수 있습니다.

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만 표시합니다.

리퍼러 및 리퍼러 정책을 보여주는 Chrome DevTools의 네트워크 패널 스크린샷 — Chrome DevTools의 **네트워크** 패널에 요청이 선택되어 있습니다.

웹사이트에 어떤 정책을 설정해야 하나요?

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에서 새 기본 정책을 변경해도 이 동작은 변경되지 않습니다.

결론

보호되는 리퍼러 정책은 사용자의 개인 정보를 더 안전하게 보호하는 데 좋은 방법입니다.

사용자를 보호하는 다양한 기술에 관한 자세한 내용은 안전 및 보안 컬렉션을 참고하세요.

자료

모든 검토자(특히 카우스투바 고빈드, 데이비드 반 클레브, 마이크 웨스트, 샘 더튼, 로완 메어우드, 잭, 케이스 바스크스)에게 기여하고 의견을 주신 데 대해 많은 감사를 드립니다.

리퍼러 및 리퍼러 정책 권장사항

요약

리퍼러 및 리퍼러 정책 101

어떤 정책을 사용할 수 있으며 정책이 어떻게 다른가요?

브라우저의 기본 리퍼러 정책

리퍼러 정책 설정 권장사항

리퍼러 정책을 확인하는 방법

웹사이트에 어떤 정책을 설정해야 하나요?

'명시적'인 이유는 무엇인가요?

strict-origin-when-cross-origin (또는 더 엄격한) 기준을 적용하는 이유는 무엇인가요?

strict-origin-when-cross-origin (또는 더 엄격한)가 모든 사용 사례를 수용하지 못하면 어떻게 해야 하나요?

예: 요소 수준 정책

예시: 요청 수준 정책

그 밖에 무엇을 고려해야 하나요?

수신 요청에 대한 권장사항

사용자 데이터 보호

수신되는 리퍼러는 {referer-can-change}을(를) 변경할 수 있습니다.

Referer의 대안

출처만 필요한 경우

URL의 다른 요소 (경로, 쿼리 매개변수 등)가 필요한 경우

다음 대안을 사용할 수 없는 경우 다음 안내를 따르세요.

크로스 사이트 요청 위조 (CSRF) 방지

로깅 및 디버그

지불

결제 흐름 보안 확인을 위한 권장사항

결론

자료

`strict-origin-when-cross-origin` (또는 더 엄격한) 기준을 적용하는 이유는 무엇인가요?

`strict-origin-when-cross-origin` (또는 더 엄격한)가 모든 사용 사례를 수용하지 못하면 어떻게 해야 하나요?

`Referer`의 대안