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

Maud Nalpas

이 페이지에서는 Referrer-Policy를 설정하고 수신 요청에서 리퍼러를 사용하는 몇 가지 권장사항을 설명합니다.

요약

• 예상치 못한 교차 출처 정보 유출은 웹 사용자의 개인 정보를 손상시킵니다. 보호 리퍼러 정책이 도움이 될 수 있습니다.
• strict-origin-when-cross-origin의 리퍼러 정책을 설정하는 것이 좋습니다. 교차 출처 데이터 유출 위험을 완화하면서 리퍼러의 유용성을 대부분 유지합니다.
• 교차 사이트 요청 위조 (CSRF) 보호에 리퍼러를 사용하지 마세요. 대신 CSRF 토큰 과 기타 헤더를 추가 보안 계층으로 사용하세요.

리퍼러 및 Referrer-Policy 101

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

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

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

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

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

Referer 값에서 많은 것을 알 수 있습니다. 예를 들어 분석 서비스는 이를 사용하여 site-two.example 방문자의 50% 가 social-network.example에서 왔다고 판단할 수 있습니다. 하지만 경로 및 쿼리 문자열을 포함한 전체 URL이 Referer 출처 간 `Referer`로 전송되면 사용자 개인 정보를 위험에 빠뜨리고 보안 위험을 초래할 수 있습니다.

URL #1~ #5에는 비공개 정보가 포함되어 있으며 민감하거나 식별 정보가 포함된 경우도 있습니다. 이러한 정보를 출처 간에 자동으로 유출하면 웹 사용자의 개인 정보가 침해될 수 있습니다.

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

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

사용 가능한 정책과 차이점은 무엇인가요?

8가지 정책 중 하나를 선택할 수 있습니다. 정책에 따라 Referer 헤더 (document.referrer)에서 사용할 수 있는 데이터는 다음과 같습니다.

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

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

다음 표에서는 리퍼러 정책이 리퍼러 헤더 및 document.referrer에서 사용할 수 있는 URL 데이터를 제한하는 방법을 보여줍니다.

MDN은 정책 및 동작 예시의 전체 목록을 제공합니다.

• HTTP 헤더
• HTML 내 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는 표시합니다.

웹사이트에 설정해야 하는 정책은 무엇인가요?

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-originno-referrerstrict-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에서 더 적은 데이터를 수신합니다.
• 브라우저는 기본적으로 Referrer-Policy 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 사용자의 개인 정보 보호를 강화하며 미래에 대비할 수 있습니다.
  • 단점: 본인 또는 시스템 사용자의 작업이 더 많아질 수 있습니다.
• 요청을 발신하는 사이트에서 요소별 또는 요청별 Referrer-Policy 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 값 목록을 설정할 때는 출처만 포함하고 경로는 포함하지 마세요.
  • 예를 들어 Referer의 허용된 online-shop.example 값은 online-shop.example이어야 하며 online-shop.example/cart/checkout이 아니어야 합니다. Referer가 전혀 없거나 요청 사이트의 출처만 있는 Referer 값을 예상하면 판매자의 Referrer-Policy에 관해 가정할 때 발생할 수 있는 오류를 방지할 수 있습니다.
• Referer가 없거나 있고 기본 Referer 출처 검사가 성공하면 다른 더 신뢰할 수 있는 확인 방법으로 이동할 수 있습니다.

결제를 더 안정적으로 확인하려면 요청자가 고유 키와 함께 요청 매개변수를 해시 하도록 하세요. 그러면 결제 제공업체는 자체적으로 동일한 해시를 계산 하고 계산과 일치하는 경우에만 요청을 수락할 수 있습니다.

리퍼러 정책이 없는 HTTP 판매자 사이트가 HTTPS 결제 제공업체로 리디렉션될 때 Referer는 어떻게 되나요?

대부분의 브라우저는 웹사이트에 정책이 설정되어 있지 않은 경우 기본적으로 strict-origin-when-cross-origin 또는 no-referrer-when-downgrade를 사용하므로 HTTPS 결제 제공업체에 대한 요청에 Referer가 표시되지 않습니다. Chrome의 새 기본 정책으로의 변경 은 이 동작을 변경하지 않습니다.

결론

보호 리퍼러 정책은 사용자에게 더 많은 개인 정보를 제공하는 좋은 방법입니다.

사용자를 보호하는 다양한 기법에 관해 자세히 알아보려면 안전한 보안 컬렉션을 참고하세요.

리소스

• '동일 사이트' 및 '동일 출처' 이해
• 새 보안 헤더: 리퍼러 정책(2017)
• MDN의 Referrer-Policy
• MDN의 리퍼러 헤더: 개인 정보 보호 및 보안 문제
• Chrome 변경사항: Blink 구현 인텐트
• Chrome 변경사항: Blink 배송 인텐트
• Chrome 변경사항: 상태 항목
• Chrome 변경사항: 85 베타 블로그 게시물
• 리퍼러 트리밍 GitHub 스레드: 다양한 브라우저의 동작
• Referrer-Policy 사양

모든 검토자, 특히 Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck, Kayce Basques의 기여와 의견에 감사드립니다.