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

Maud Nalpas
Maud Nalpas

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

요약

  • 예상치 못한 교차 출처 정보 유출로 인해 웹 사용자가 피해를 입음 있습니다. 가 보호 리퍼러 정책이 도움이 될 수 있습니다
  • 리퍼러 정책을 strict-origin-when-cross-origin로 설정해 보세요. 그것은 추천의 유용성은 대부분 그대로 유지하면서도 데이터 유출을 방지할 수 있습니다
  • 교차 사이트 요청 위조 (CSRF) 보호를 위해 리퍼러를 사용하지 않습니다. 사용 CSRF 토큰 추가 보안 계층으로 사용할 수 있는 다른 헤더들을 사용할 수 있습니다.
를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

리퍼러 및 리퍼러 정책 101

HTTP 요청에는 선택적 Referer 헤더가 포함될 수 있습니다. : 요청이 이루어진 출처 또는 웹페이지 URL을 나타냅니다. 이 Referrer-Policy 헤더 Referer 헤더에서 사용할 수 있는 데이터를 정의합니다.

다음 예에서 Referer 헤더는 다음의 전체 URL을 포함합니다. 요청을 보낸 site-one의 페이지

<ph type="x-smartling-placeholder">
</ph> 리퍼러 헤더가 포함된 HTTP 요청
리퍼러 헤더가 포함된 HTTP 요청

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

  • 탐색 요청(사용자가 링크를 클릭할 때)
  • 하위 리소스 요청(브라우저에서 이미지, iframe, 스크립트 및 페이지에 필요한 다른 리소스가 포함되어 있습니다.

탐색 및 iframe의 경우 document.referrer

Referer 값에서 많은 것을 배울 수 있습니다. 예를 들어 분석 서비스는 이를 이용해 site-two.example 방문자의 50% 가 최저가: social-network.example 그러나 경로 및 Referer를 통해 전송되는 쿼리 문자열이 있는 경우, 사용자를 위험에 빠뜨릴 수 있습니다. 개인 정보를 보호하고 보안 위험을 야기할 수 있습니다.

<ph type="x-smartling-placeholder">
</ph> 경로가 포함된 URL(다른 개인 정보 보호 및 보안 위험에 매핑됨)
전체 URL을 사용하면 사용자 개인 정보 보호에 영향을 줄 수 있습니다. 살펴봤습니다

1번에서 5번까지 URL에 개인 정보가 포함되어 있으며 식별할 수 있습니다. 이러한 정보를 출처 전반에 걸쳐 은밀하게 유출하면 웹 사용자 있습니다.

URL 6은 기능 URL입니다. 사용자가 의도한 사용자가 받는 것 외에는 악의적인 행위자가 액세스 권한이 있어야 합니다.

사이트 요청에 사용할 수 있는 리퍼러 데이터를 제한하려면 리퍼러 정책을 설정할 수 있습니다

사용 가능한 정책은 무엇이며 어떻게 다른가요?

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

  • 데이터 없음 (Referer 헤더가 없음)
  • origin
  • 전체 URL: 출처, 경로, 쿼리 문자열
를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder">데이터를
    리퍼러 헤더와 document.referrer에 포함되어 있어야 합니다.</ph>
리퍼러 데이터의 예

일부 정책은 컨텍스트에 따라 다르게 작동하도록 설계되었습니다. 교차 출처 또는 동일한 출처 요청의 경우, 요청 대상이 원본으로 보호하거나 둘 다로 설정할 수 있습니다. 이렇게 하면 정보의 양을 제한하고 풍부함을 유지하면서도 출처 간 공유 또는 보안 수준이 낮은 출처에 공유 의 실제 데이터를 확인합니다.

다음 표는 리퍼러 정책이 사용 가능한 URL 데이터를 제한하는 방식을 보여줍니다. 리퍼러 헤더 및 document.referrer에서 다음과 같이 작성합니다.

정책 범위 정책 이름 리퍼러: 데이터 없음 리퍼러: 출처만 리퍼러: 전체 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 출처(HTTP는 보안 수준이 낮음) 그 이유는 정책에서 중요한 것은 보안 다운그레이드가 발생하는지 여부입니다. 저것 요청이 암호화된 출처의 데이터를 암호화되지 않은 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-originunsafe-url은 크로스 사이트 요청에서 무시됩니다. 즉, 리퍼러가 항상 잘립니다. 크로스 사이트 요청에 사용할 수 있습니다.
에지 기본값은 strict-origin-when-cross-origin입니다.
Safari 기본값은 strict-origin-when-cross-origin와 비슷합니다. 몇 가지 구체적인 차이점이 있습니다 자세한 내용은 <ph type="x-smartling-placeholder"></ph> 추적 방지 추적 방지를 참고하세요.

리퍼러 정책 설정 권장사항

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

페이지, 요청 또는 요소마다 다른 정책을 설정할 수 있습니다.

HTTP 헤더와 메타 요소는 모두 페이지 수준입니다. 인코더-디코더 아키텍처를 요소의 유효 정책을 결정하는 방법은 다음과 같습니다.

  1. 요소 수준 정책
  2. 페이지 수준 정책
  3. 브라우저 기본값

예:

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 전송됩니다.

<ph type="x-smartling-placeholder">
</ph> 리퍼러 및 Referrer-Policy가 표시된 Chrome DevTools의 네트워크 패널 스크린샷 <ph type="x-smartling-placeholder">
</ph> Chrome DevTools 요청이 선택된 Network 패널

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

다음과 같이 개인 정보 보호 강화 정책을 명시적으로 설정하는 것이 좋습니다. 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-originstrict-origin는 출처만 공유합니다. 그리고 no-referrer는 아무것도 공유하지 않습니다. 이렇게 하면 다음 형식으로 strict-origin-when-cross-origin, strict-origin, no-referrer 개인 정보 보호 강화 옵션을 제공합니다.
  • 유용성: no-referrerstrict-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, 필요하다면 더 많은 허용 정책을 지정합니다.

예: 요소 수준 정책

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에 식별 정보나 민감한 정보가 포함되어 있는 경우 보호 정책을 설정할 수 있습니다

수신 요청에 관한 권장사항

다음은 사이트에서 할 수 있습니다.

사용자 보호 데이터

Referer에는 비공개, 개인 또는 식별 데이터가 포함될 수 있으므로 그렇게 취급하는 것입니다.

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

수신되는 교차 출처 요청에서 리퍼러를 사용할 때는 다음과 같은 몇 가지 제한사항이 있습니다.

  • 요청 내보내기의 구현을 제어할 수 없는 경우 다음을 수행할 수 없습니다. Referer 헤더 (및 document.referrer)에 대해 가정합니다. 해야 합니다. 요청 이미터가 no-referrer 정책으로 전환하도록 결정할 수 있음 보다 일반적으로 엄격한 정책 위반에 대해 사용됩니다. 즉, Referer에서 이전보다 더 적은 데이터를 수신합니다.
  • 점점 더 많은 브라우저에서 리퍼러 정책 strict-origin-when-cross-origin 사용 기본적으로 제공됩니다 즉, 이제 전체 객체가 아닌 수신되는 교차 출처 요청에서 전체 리퍼러 URL(발신자 사이트가 정책이 설정되지 않았습니다.
  • 브라우저에서 Referer 관리 방식을 변경할 수도 있습니다. 예를 들어 일부 브라우저 개발자는 항상 교차 출처의 출처로 리퍼러를 자를 수 있음 하위 리소스 요청을 사용하여 사용자 개인 정보를 보호할 수 있습니다.
  • Referer 헤더 (및 document.referrer)에는 다음보다 더 많은 데이터가 포함될 수 있습니다. 알 수 있습니다. 예를 들어 사용자가 교차 출처 요청인지 확인합니다

Referer의 대안

다음과 같은 경우 대안을 고려해야 할 수 있습니다.

  • 사이트의 필수 기능에서 사이트의 교차 출처 요청을 수행합니다
  • 사이트가 교차 출처 요청을 수행합니다 이는 요청 이미터가 정책이 설정되어 있지 않고 브라우저 기본값 정책이 변경된 경우 (예: Chrome 85)

대안을 정의하려면 먼저 리퍼러에서 사용 중인 부분을 분석합니다.

원본만 필요한 경우

  • 페이지에 대한 최상위 액세스 권한이 있는 스크립트에서 리퍼러를 사용하는 경우 대신 window.location.origin를 사용할 수 있습니다.
  • 가능한 경우 OriginSec-Fetch-Site Origin를 제공하거나 요청이 교차 출처인지 설명 정확히 원하는 내용일 수 있습니다.

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

  • 요청 매개변수를 사용하면 사용 사례를 처리할 수 있으므로 리퍼러 파싱하기
  • 페이지에 대한 최상위 액세스 권한이 있는 스크립트에서 리퍼러를 사용하는 경우 window.location.pathname를 대신 사용해 보세요. 경로만 추출 섹션을 만들고 인수로 전달하므로 민감할 수 있는 모든 매개변수는 정보는 전달되지 않습니다.

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

  • 요청 이미터를 받을 수 있도록 시스템을 변경할 수 있는지 확인 (예: 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 헤더 자체는 신뢰할 수 있는 기반이 아닙니다. 확인 합법적인 판매자인지 여부와 관계없이 요청 사이트는 no-referrer 정책을 통해 Referer 결제 시스템 공급자

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 판매자 사이트인 경우 Referer은 어떻게 되나요? 정책이 HTTPS 결제 제공업체로 리디렉션되나요?

HTTPS 결제 시스템 공급자 요청에 Referer이 표시되지 않습니다. 대부분의 브라우저strict-origin-when-cross-origin 또는 웹사이트에 정책이 설정되지 않은 경우 기본적으로 no-referrer-when-downgrade입니다. 새로운 기본 정책으로의 Chrome 변경사항 이 동작을 변경하지는 않습니다.

결론

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

사용자를 보호하기 위한 다양한 기술에 대해 자세히 알아보려면 다음을 참조하세요. 안전한 수집

리소스

모든 검토자, 특히 KauTubeha Govind에게 기여와 의견에 감사드립니다. 데이비드 밴 클레브, 마이크 웨스트, 샘 더튼, 로완 메어우드, Jxck, 케이스 바스케스