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

Maud Nalpas

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

요약

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

리퍼러 및 리퍼러 정책 101

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

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

</ph>

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

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

탐색 및 iframe의 경우 document.referrer

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

</ph>

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

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

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

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

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

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

</ph> <ph type="x-smartling-placeholder"></ph>

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

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

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월 기준

리퍼러 정책이 설정되지 않으면 브라우저에서 기본 정책을 사용합니다.

리퍼러 정책 설정 권장사항

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

• HTTP 헤더로
• HTML
• JavaScript에서 요청별로 생성

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

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> <ph type="x-smartling-placeholder">

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

다음과 같이 개인 정보 보호 강화 정책을 명시적으로 설정하는 것이 좋습니다. 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, 필요하다면 더 많은 허용 정책을 지정합니다.

예: 요소 수준 정책

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를 사용할 수 있습니다.
• 가능한 경우 Origin 및 Sec-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 변경사항 이 동작을 변경하지는 않습니다.

결론

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

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

리소스

• 'same-site' 이해 및 'same-origin'
• 새로운 보안 헤더: 리퍼러 정책 (2017년)
• 리퍼러 정책 사용 MDN
• 리퍼러 헤더: 개인 정보 보호 및 보안 문제 관련 MDN
• Chrome 변경: 인텐트를 깜박임 구현
• Chrome 변경: 인텐트를 깜박임 배송
• Chrome 변경: 상태 항목
• Chrome 변경: 85 베타 blogpost
• 리퍼러 자르기 GitHub 스레드: 다양한 브라우저의 종류 해야 할 일
• 리퍼러 정책 사양

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