추천인 정책

1. 소개

이 섹션은 규범적인 내용이 아닙니다.

문서에서 이루어진 요청과 그 문서로부터의 네비게이션은 Referer 헤더와 연관되어 있습니다. 이 헤더는 noreferrer 링크 타입을 가진 링크에 대해 억제할 수 있지만, 저자는 다양한 이유로 Referer 헤더를 보다 직접적으로 제어하고 싶을 수 있습니다:

1.1. 프라이버시

소셜 네트워킹 사이트에는 각 사용자별 프로필 페이지가 있으며, 사용자는 자신의 프로필 페이지에서 좋아하는 밴드로 하이퍼링크를 추가합니다. 소셜 네트워킹 사이트는 다른 사용자가 해당 하이퍼링크를 따라갈 때, 밴드 웹사이트에 사용자의 프로필 URL이 누출되는 것을 원하지 않을 수 있습니다(프로필 URL이 프로필 소유자의 신원을 드러낼 수 있기 때문입니다).

하지만 일부 소셜 네트워킹 사이트는 밴드 웹사이트에 링크가 소셜 네트워킹 사이트에서 비롯되었음을 알리되, 어떤 특정 사용자의 프로필에서 링크가 포함되었는지는 공개하지 않을 수도 있습니다.

1.2. 보안

웹 애플리케이션이 HTTPS와 URL 기반 세션 식별자를 사용합니다. 웹 애플리케이션은 사용자의 세션 식별자가 URL에 포함된 채로 다른 웹사이트의 HTTPS 리소스로 링크할 때, 세션 식별자가 누출되지 않도록 하고 싶을 수 있습니다.

또는 웹 애플리케이션이 자체적으로 능력을 부여하는 URL을 사용할 수도 있습니다. 추천인(referrer)을 제어하면 이러한 capability URL이 추천인 헤더를 통해 누출되는 것을 방지하는 데 도움이 됩니다. [CAPABILITY-URLS]

능력 부여 URL이 누출되는 다른 방식도 있으므로, 추천인을 제어하는 것만으로 모든 잠재적 누출을 막을 수 있는 것은 아니라는 점에 유의해야 합니다.

1.3. 트랙백

HTTPS로 호스팅되는 블로그가 HTTP로 호스팅되는 블로그에 링크를 걸고 트랙백 링크를 받고자 할 수 있습니다.

2. 핵심 개념 및 용어

추천인 정책

추천인 정책은 Referer 헤더를 채우는 알고리즘을 서브리소스 fetch, 프리페치, 네비게이션을 수행할 때 수정합니다. 이 문서는 각 추천인 정책에 대한 다양한 동작을 정의합니다.

모든 environment settings object는 추천인 정책을 얻는 알고리즘을 가지며, 이는 해당 environment settings object를 client로 갖는 모든 요청에 기본적으로 사용됩니다.

동일 출처 요청

Request request가 동일 출처 요청이 되려면 request의 origin과 request의 current url의 origin이 the same여야 합니다.

교차 출처 요청

Request 가 동일 출처가 아닌 경우 교차 출처 요청입니다.

3. 추천인 정책

추천인 정책 은 빈 문자열, "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", 또는 "unsafe-url"입니다.

enum ReferrerPolicy {
  "",
  "no-referrer",
  "no-referrer-when-downgrade",
  "same-origin",
  "origin",
  "strict-origin",
  "origin-when-cross-origin",
  "strict-origin-when-cross-origin",
  "unsafe-url"
};

각 가능한 추천인 정책은 아래에서 설명합니다. 이들의 효과를 평가하는 상세 알고리즘은 §5 Fetch와의 통합 및 §8 알고리즘 섹션에서 제시합니다.

참고: environment settings object의 추천인 정책은 해당 environment settings object가 request client로 사용될 때 요청의 기본 정책 역할을 합니다. 이 정책은 noreferrer 링크 타입과 같은 메커니즘을 통해 특정 요청에 대해 더욱 강화될 수 있습니다.

3.1. "no-referrer"

가장 단순한 정책은 "no-referrer"로, 특정 request client에서 어떤 origin으로 요청을 보낼 때 추천인 정보를 전송하지 않도록 지정합니다. 헤더는 완전히 생략됩니다.

3.2. "no-referrer-when-downgrade"

"no-referrer-when-downgrade" 정책은 TLS로 보호된 environment settings object에서 잠재적으로 신뢰할 수 있는 URL로의 요청과, TLS로 보호되지 않은 client에서 어떤 origin으로의 요청에 대해 전체 URL을 전송합니다.

TLS로 보호된 client에서 비-잠재적으로 신뢰할 수 있는 URL로의 요청에는 추천인 정보가 포함되지 않습니다. Referer HTTP 헤더가 전송되지 않습니다.

이것이 별도의 정책이 지정되지 않았을 때 사용자 에이전트의 기본 동작입니다.

3.3. "same-origin"

"same-origin" 정책은 특정 client에서 추천인으로 사용하기 위해 스트립된 전체 URL을 동일 출처 요청에 추천인 정보로 전송하도록 지정합니다.

교차 출처 요청에는 추천인 정보가 포함되지 않으며, Referer HTTP 헤더가 전송되지 않습니다.

3.4. "origin"

"origin" 정책은 특정 request client에서 ASCII 직렬화된 origin만을 동일 출처 요청 및 교차 출처 요청에 추천인 정보로 전송하도록 지정합니다.

참고: origin의 직렬화 결과는 https://example.com과 같습니다. 사용자 에이전트는 Referer 헤더에 올바른 URL을 전송하기 위해 origin 뒤에 U+002F SOLIDUS("/") 문자를 추가합니다(예: https://example.com/).

참고: "origin" 정책은 HTTPS 추천인의 origin을 암호화되지 않은 HTTP 요청에도 네트워크로 전송하게 만듭니다. "strict-origin" 정책은 이 문제를 해결합니다.

3.5. "strict-origin"

"strict-origin" 정책은 다음과 같이 ASCII 직렬화된 origin을 추천인 정보로 전송합니다:

• TLS로 보호된 environment settings object에서 잠재적으로 신뢰할 수 있는 URL로 요청 시,
• TLS로 보호되지 않은 environment settings object에서 어떤 origin으로의 요청 시

TLS로 보호된 request client에서 비-잠재적으로 신뢰할 수 있는 URL로의 요청에는 추천인 정보가 포함되지 않습니다. Referer HTTP 헤더가 전송되지 않습니다.

3.6. "origin-when-cross-origin"

"origin-when-cross-origin" 정책은 특정 request client에서 추천인으로 사용하기 위해 스트립된 전체 URL을 동일 출처 요청에 추천인 정보로 전송하고, ASCII 직렬화된 origin만을 교차 출처 요청에 추천인 정보로 전송하도록 지정합니다.

참고: "origin-when-cross-origin" 정책에서는 프로토콜 업그레이드(예: http://example.com/에서 https://example.com/으로의 요청) 역시 교차 출처 요청으로 간주합니다.

참고: "origin-when-cross-origin" 정책은 HTTPS 추천인의 origin을 암호화되지 않은 HTTP 요청에도 네트워크로 전송하게 만듭니다. "strict-origin-when-cross-origin" 정책은 이 문제를 해결합니다.

3.7. "strict-origin-when-cross-origin"

"strict-origin-when-cross-origin" 정책은 특정 request client에서 추천인으로 사용하기 위해 스트립된 전체 URL을 동일 출처 요청에 추천인 정보로 전송하고, ASCII 직렬화된 origin만을 교차 출처 요청에 추천인 정보로 전송합니다:

• TLS로 보호된 environment settings object에서 잠재적으로 신뢰할 수 있는 URL로 요청 시,
• TLS로 보호되지 않은 environment settings object에서 어떤 origin으로의 요청 시

TLS로 보호된 client에서 비-잠재적으로 신뢰할 수 있는 URL로의 요청에는 추천인 정보가 포함되지 않습니다. Referer HTTP 헤더가 전송되지 않습니다.

3.8. "unsafe-url"

"unsafe-url" 정책은 특정 client에서 추천인으로 사용하기 위해 스트립된 전체 URL을 교차 출처 요청 및 동일 출처 요청 모두에 추천인 정보로 전송하도록 지정합니다.

참고: 정책 이름에서 알 수 있듯이, 이 정책은 안전하지 않습니다. 이 정책은 TLS로 보호된 리소스의 origin과 경로가 안전하지 않은 origin으로 누출될 수 있습니다. 민감한 문서에 이 정책을 설정할 때는 반드시 그 영향을 신중히 고려해야 합니다.

3.9. 빈 문자열

빈 문자열 ""은 추천인 정책이 없음을 의미하며, 다른 곳에 정의된 추천인 정책으로 폴백되거나, 더 상위 정책이 없을 경우 "no-referrer-when-downgrade"로 기본 동작합니다. 이러한 기본 동작은 §8.3 요청의 추천인 결정 알고리즘에서 처리됩니다.

4. 추천인 정책 전달

요청의 추천인 정책은 다섯 가지 방법 중 하나로 전달됩니다:

• Referrer-Policy HTTP 헤더를 통해 (§4.1 Referrer-Policy 헤더를 통한 전달에서 정의됨)
• meta 요소에서 name 속성이 referrer인 경우
• referrerpolicy 콘텐츠 속성을 가진 a, area, img, iframe, 또는 link 요소를 통해
• noreferrer 링크 관계를 가진 a, area, 또는 link 요소를 통해
• 암묵적으로 상속을 통해

4.1. Referrer-Policy 헤더를 통한 전달

Referrer-Policy HTTP 헤더는 사용자 에이전트가 요청 시 어떤 추천인 정보를 포함할지 결정할 때 적용하는 추천인 정책을 지정합니다. 또한 보호된 리소스의 컨텍스트에서 생성된 브라우징 컨텍스트에도 적용됩니다. 헤더의 이름과 값에 대한 문법은 다음 ABNF 문법으로 설명됩니다:

"Referrer-Policy:" 1#policy-token

policy-token   = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"

참고: 헤더 이름은 HTTP Referer 헤더의 오타를 공유하지 않습니다.

§5 Fetch와의 통합 및 §6 HTML과의 통합에서 Referrer-Policy 헤더가 어떻게 처리되는지 설명합니다.

Referrer-Policy: no-referrer

<a href="http://example.com" referrerpolicy="origin">

7. CSS와의 통합

CSS 표준은 스타일시트에서 참조된 리소스를 어떻게 fetch하는지 명시하지 않습니다. 그러나 구현체는 스타일시트에서 시작된 요청의 추천인 관련 속성을 다음과 같이 설정해야 합니다:

1. CSS 선언 블록이 요청의 원인일 경우, 추천인은 블록의 owner node의 node document의 URL로 설정하고, 추천인 정책은 블록의 owner node의 node document의 추천인 정책으로 설정함
2. CSS 스타일 시트가 요청의 원인이고, location이 null이 아니라면, 추천인은 location으로, 추천인 정책은 추천인 정책으로 설정함

   이는 CSS 스타일 시트가 `Referrer-Policy` 헤더를 처리하고, 추천인 정책을 문서(Document)와 동일한 방식으로 저장해야 함을 의미합니다.

3. 그 외의 경우, CSS 스타일 시트의 location이 null이면, 추천인은 owner node의 node document의 URL로 설정하고, 추천인 정책은 블록의 owner node의 node document의 추천인 정책으로 설정함

참고: 요청의 추천인 값과 추천인 정책 값은 해당 요청이 생성되는 시점의 값을 기준으로 설정됩니다. 문서의 추천인 정책이 생명주기 중에 변경되면 인라인 스타일시트 요청에 연관된 정책도 변경됩니다.

8. 알고리즘

8.1. Referrer-Policy 헤더에서 추천인 정책 구문 분석

Response response가 주어졌을 때, 아래 단계는 response의 `Referrer-Policy` 헤더에 따라 추천인 정책을 반환합니다:

1. policy-tokens에 response의 헤더 리스트에서 `Referrer-Policy`를 파싱한 결과를 할당합니다.
2. policy에 빈 문자열을 할당합니다.
3. policy-tokens의 각 token에 대해, token이 추천인 정책이고 빈 문자열이 아니면 policy에 token을 할당합니다.

   참고: 이 알고리즘은 더 오래된 사용자 에이전트에 대한 폴백과 함께 새로운 정책 값을 배포할 수 있도록 여러 정책 값을 반복합니다. 자세한 내용은 §11.1 알 수 없는 정책 값을 참고하세요.

4. policy를 반환합니다.

8.2. 리디렉션 시 request의 추천인 정책 설정

request request와 response actualResponse가 주어지면, 이 알고리즘은 actualResponse의 Referrer-Policy 헤더(있는 경우)에 따라 request에 연결된 추천인 정책을 갱신합니다.

1. policy에 actualResponse에 대해 §8.1 Referrer-Policy 헤더에서 추천인 정책 구문 분석을 실행한 결과를 할당합니다.
2. policy가 빈 문자열이 아니면 request에 연결된 추천인 정책을 policy로 설정합니다.

8.3. request의 추천인 결정

Request request가 주어졌을 때, 연결된 추천인 정책을 검사하여 전송할 올바른 추천인 정보를 결정할 수 있습니다. 아래 단계에 따라 추천인 없음 또는 URL을 반환합니다:

1. policy에 request의 연결된 추천인 정책을 할당합니다.
2. environment에 request의 client를 할당합니다.
3. request의 추천인 값에 따라 분기합니다:

   "client"

   1. environment의 global object가 Window 객체라면
      1. document에 environment의 global object에 연결된 Document를 할당합니다.
      2. document의 origin이 불투명 origin이면 추천인 없음을 반환합니다.
      3. document가 iframe srcdoc 문서일 때, document를 document의 브라우징 컨텍스트의 브라우징 컨텍스트 컨테이너의 node document로 바꿉니다.
      4. referrerSource에 document의 URL을 할당합니다.
   2. 그 외의 경우 referrerSource에 environment의 생성 URL을 할당합니다.

   URL

   referrerSource에 request의 추천인 값을 할당합니다.

   참고: request의 추천인이 "no-referrer"인 경우, Fetch는 이 알고리즘을 호출하지 않습니다.

4. referrerURL에 추천인으로 사용하기 위해 referrerSource를 스트립한 결과를 할당합니다.
5. referrerOrigin에 추천인으로 사용하기 위해 referrerSource를 스트립한 결과(여기서 origin-only flag는 true임)를 할당합니다.
6. policy의 값에 따라 다음을 실행합니다:

   "no-referrer"

   추천인 없음을 반환

   "origin"

   referrerOrigin을 반환

   "unsafe-url"

   referrerURL을 반환

   "strict-origin"

   1. environment가 null이 아니면:
      1. environment가 TLS로 보호된 상태이고 request의 current URL이 잠재적으로 신뢰할 수 있는 URL이 아니면 추천인 없음을 반환합니다.
   2. referrerOrigin을 반환합니다.

   "strict-origin-when-cross-origin"

   1. request가 동일 출처 요청이면 referrerURL을 반환합니다.
   2. environment가 null이 아니면:
      1. environment가 TLS로 보호된 상태이고 request의 current URL이 잠재적으로 신뢰할 수 있는 URL이 아니면
         1. 추천인 없음을 반환합니다.
   3. referrerOrigin을 반환합니다.

   "same-origin"

   1. request가 동일 출처 요청이면 referrerURL을 반환합니다.
   2. 그 외에는 추천인 없음을 반환합니다.

   "origin-when-cross-origin"

   1. request가 교차 출처 요청이면 referrerOrigin을 반환합니다.
   2. 그 외에는 referrerURL을 반환합니다.

   "no-referrer-when-downgrade"

   1. environment가 null이 아니면:
      1. environment가 TLS로 보호된 상태이고 request의 current URL이 잠재적으로 신뢰할 수 있는 URL이 아니면 추천인 없음을 반환합니다.
   2. referrerURL을 반환합니다.

   참고: Fetch는 이 알고리즘을 호출하기 전에 request의 추천인 정책이 빈 문자열이 아닌지 확인합니다.

8.4. 추천인으로 사용하기 위해 url 스트립

URL의 일부 구성요소는 `Referer` 헤더 값으로 전송할 때 반드시 포함되지 않아야 합니다: URL의 fragment, username, password 구성요소는 전송 전에 반드시 제거되어야 합니다. 이 알고리즘은 기본값이 false인 origin-only flag를 받으며, true로 설정하면 URL의 경로와 쿼리 구성요소까지 추가로 제거하여 scheme, host, port만 남깁니다.

1. url이 null이면 추천인 없음을 반환합니다.
2. url의 scheme이 로컬 scheme이면 추천인 없음을 반환합니다.
3. url의 username을 빈 문자열로 설정합니다.
4. url의 password를 null로 설정합니다.
5. url의 fragment를 null로 설정합니다.
6. origin-only flag가 true라면:
   1. url의 path를 null로 설정합니다.
   2. url의 query를 null로 설정합니다.
7. url을 반환합니다.

9. 프라이버시 고려사항

9.1. 사용자 제어

이 명세의 어느 부분도 사용자 에이전트가 `Referer` 헤더를 통해 전송되는 정보를 변경할 수 있는 옵션을 사용자에게 제공하는 것을 금지하는 것으로 해석되어서는 안 됩니다. 예를 들어, 사용자 에이전트는 페이지의 활성 추천인 정책과 관계없이 추천인 헤더를 완전히 숨길 수 있도록 허용할 수 있습니다(MAY).

10. 보안 고려사항

10.1. 정보 누출

추천인 정책 중 "origin", "origin-when-cross-origin", "unsafe-url"는 각각 안전하지 않은 전송을 통해 보안 사이트의 origin 또는 URL을 누출할 수 있습니다.

이 세 가지 정책은 사이트가 안전한 전송을 도입하는 데 마찰을 줄이고자 명세에 포함되었습니다.

기본 정책보다 더 많은 정보가 누출되지 않도록 하고 싶은 저자는 "same-origin", "strict-origin", "strict-origin-when-cross-origin" 또는 "no-referrer" 정책 상태를 사용하는 것이 좋습니다.

10.2. 덜 엄격한 정책으로 다운그레이드

이 명세는 "no-referrer"에서 "unsafe-url"로와 같이 덜 엄격한 정책으로 다운그레이드하는 것을 금지하지 않습니다.

한편, 모든 가능한 정책 쌍에 대해 어느 정책이 더 엄격한지 명확하지 않을 수 있습니다. 예를 들어 "no-referrer-when-downgrade"는 안전하지 않은 전송에서는 정보를 누출하지 않지만, "origin"은 그럴 수 있습니다. 하지만 후자는 교차 출처 네비게이션에서는 더 적은 정보를 노출합니다.

다른 한편으로, 덜 엄격한 정책을 설정할 수 있도록 허용하면 §11.1 알 수 없는 정책 값에서 설명한 안전한 폴백을 저자가 정의할 수 있습니다.

11. 저작 고려사항

11.1. 알 수 없는 정책 값

§8.1 Referrer-Policy 헤더에서 추천인 정책 구문 분석 및 meta referrer 알고리즘에서 설명한 바와 같이, 알 수 없는 정책 값은 무시되며 여러 소스에서 추천인 정책이 지정될 경우 가장 마지막 값을 사용합니다. 이를 통해 새로운 정책 값을 배포할 수 있습니다.

하지만 이러한 동작은 referrerpolicy 속성에는 적용되지 않습니다. 저자는 특정 정책 값이 지원되는지 감지하기 위해 referrerpolicy 속성을 동적으로 설정하고 얻을 수 있습니다.

12. 감사의 말씀

이 명세는 Adam Barth와 Jochen Eisinger의 Meta referrer 문서를 크게 참고하였습니다.