연결 허용 목록

1. 소개

개발자는 자신의 페이지 컨텍스트에 로드되는 리소스와 페이지가 요청을 보낼 수 있는 엔드포인트를 제어하기를 원합니다. 이러한 제어는 여러 목적에 필요하며, 여기에는 사용자 데이터가 사용자 에이전트를 통해 흐를 수 있는 방식을 제한하는 것(유출 공격 완화)과 사이트의 아키텍처 및 의존성에 대한 제어 보장이 포함됩니다.

Content Security Policy는 이러한 필요 중 일부를 다루지만, 가장 중요한 사용 사례에 필요한 것보다 더 세분화된 방식으로 이를 수행하며, CSP가 배포하는 다른 보호 기능 때문에 복잡해진 구문과 문법을 사용합니다. [CSP]

`Connection-Allowlist`는 CSP에서 한 걸음 물러나, 페이지가 Fetch 및 기타 웹 플랫폼 API(WebRTC, Web Transport, FedCM, Web Payments, DNS Prefetch 등)를 통해 시작할 수 있는 명시적 요청을 제어하는 단일 사용 사례에 초점을 맞춥니다. 그 목표는 단순하고 포괄적인 방식을 제공하는 것입니다.

NOTE: '\' line wrapping per RFC 8792

Connection-Allowlist: (response-origin "https://cdn.example" "https://*.example.:tld" \
                       "https://api.example:*"); report-to=ReportingAPIEndpoint

사용자가 탐색한 문서와 함께 전달되는 이 헤더는 해당 문서가 목록에 지정된 URL 패턴과 일치하는 엔드포인트로만 요청과 연결을 허용하도록 제한합니다. [URLPATTERN] 여기에는 문서가 전달된 출처, https://cdn.example, 끝에서 두 번째 DNS 레이블이 example인 모든 호스트의 모든 하위 도메인, 모든 포트의 https://api.example 등이 포함됩니다.

허용 목록과 일치하지 않는 엔드포인트에 연결하려는 시도는 차단되며, report-to 매개변수에 지정된 Reporting API [REPORTING] endpoint로 보고됩니다(그리고 별도의 Reporting-Endpoints 헤더를 통해 정의됩니다).

1.1. 위협 모델

이 제안은 의도적으로 작으며, 클라이언트 측 공격 및/또는 잘못된 구성 중 구체적이지만 유용한 틈새 영역을 대상으로 합니다:

문서와 워커에 대한 정책은 서버가 HTTP 응답 헤더로 선언합니다. 이는 응답 헤더를 조작할 수 있는 공격자는 범위 밖에 남는다는 뜻입니다.
문서(또는 워커)의 선언된 정책은 _해당_ 컨텍스트가 시작한 요청만 지배합니다. 프레임된 문서가 별도의 정책을 선언한다면 그대로 둡니다(단, 이 정책은 로컬 스킴(data:, about: 등)을 통해 생성된 컨텍스트에도 적용된다는 단서가 있습니다). 이는 새 문서/워커 컨텍스트를 만들 때 HTML이 처리하는, 컨텍스트의 policy container의 다른 구성 요소와 유사합니다.
연결 및/또는 요청은 이 제안이 방어하려는 위협입니다. 유출 방어로 효과적이려면 연결이 만들어지기 전에 차단해야 합니다.
그 외에는 훌륭한 웹 플랫폼 API의 의도치 않은 효과로 사용할 수 있는 부채널이 매우 많습니다. 이 제안은 그것들을 다루려 하지 않고, 대신 사용자 에이전트가 페이지를 대신하여 명시적으로 시작하는 요청 또는 연결에만 초점을 맞춥니다. 여기에는 fetch()와 XMLHttpRequest 같은 명확한 경우와 일반적인 리소스 요청이 확실히 포함됩니다. 또한 Web Install API를 통해 가져오는 manifest, WebRTC를 통한 TURN/STUN 서버 연결, Web Transport 채널, DNS prefetch, 탐색 등, “요청”으로 덜 명시적인 채널을 통해 설정되는 네트워크 연결도 포함됩니다. 이들은 모두 범위 안에 있지만, 메모리나 CPU 소비, 소켓 고갈, XSLeaks 전반과 같은 더 난해한 채널은 범위 밖입니다.
이 제안은 통신 채널만 다룹니다. 콘텐츠 삽입이나 크로스 사이트 스크립팅 같은 위협을 방지하거나 (심지어 실질적으로 완화하려는) 목표를 갖지 않습니다. 정책이 적용된 _그 특정 페이지들_에서 그러한 공격의 영향을 제한할 수 있을 뿐이며, 페이지 방어의 한 계층으로만 간주되어야 합니다. 그 자체만으로는 충분하지 않습니다.
오픈 리디렉션 같은 서버 측 위협의 하위 집합을 방어하려고 시도하고 싶을 수 있습니다. 클라이언트를 떠난 데이터는 근본적으로 이제 서버의 제어하에 있기 때문에, 효과적인 방식으로 그렇게 하기는 어려울 것입니다. 그렇기는 해도, 리디렉션 응답을 통해 다른 서버로 연결을 만들려는 서버의 결정에 클라이언트가 직접 협력할지 여부를 개발자가 선택할 수 있게 하는 것은 합리적으로 보입니다. 기본적으로, 대상과 관계없이 리디렉션 응답은 차단됩니다. 개발자는 헤더의 매개변수를 설정하여 모든 리디렉션 응답을 허용하도록 선택할 수 있습니다. 자세한 내용은 § 6.7 리디렉션을 참조하십시오.
마찬가지로 WebRTC 연결은 동적 엔드포인트 발견과 피어 투 피어 연결을 자주 포함하므로 URL 패턴으로 제한하기 어렵습니다. 개발자가 WebRTC 연결을 완전히 허용할지 차단할지 선택할 수 있도록 전역 토글을 제공합니다. 자세한 내용은 § 6.8 WebRTC를 참조하십시오.

1.2. Content Security Policy와의 중복

이 제안은 특정 컨텍스트 내에서 리소스 사용에 제한을 두는 Content Security Policy의 접근 방식, 특히 fetch directives와 많은 공통점을 가집니다. 그래도 몇 가지 이유로 살펴볼 가치가 있어 보입니다:

CSP의 모델은 너무 세분화되어 있습니다. 민감한 컨텍스트에서 데이터가 유출될 위험을 완화하려는 개발자는 요청이 만들어지거나 연결이 설정될 수 있는 모든 가능한 방식을 빠짐없이 포괄하는 보호가 필요합니다. CSP가 요청을 서로 독립적으로 제어할 수 있는 유형으로 분류하는 방식은 이 문제에 접근하는 잘못된 방법입니다. 웹 폰트 요청을 통해 데이터가 누출되는 것은 이미지나 스크립트 요청을 통해 데이터가 누출되는 것만큼 나쁘기 때문입니다. 이러한 요청 유형을 구분하면, 단순히 관련 없는 질문들로 인해 합리적인 방어 설계 과정이 복잡해집니다.
CSP의 구문은 충분히 세분화되어 있지 않습니다. CSP가 지원하는 host-source 문법은 응답과 함께 전달되는 매우 장황한 헤더로 이어집니다. 별도의 정책은 URLPattern 구문으로 전환할 기회를 제공하며, 이는 더 현대적이고 유연하며 표준화된 매칭 구문을 제공함으로써 CSP 접근 방식에 대해 사람들이 제기해 온 일부 불만을 해결할 것입니다.
CSP의 적용 범위는 불완전합니다. CSP는 Fetch를 통해 실행되는 HTTP 요청을 잘 다루지만, 웹 플랫폼 API가 연결을 설정할 수 있게 하는 수많은 방식을 빠짐없이 다루지는 않습니다. DNS prefetch와 WebRTC는 시작하기 좋은 예이며, 그 외에도 CSP의 위협 모델에 정확히 어떻게 들어맞는지 어려움을 겪어 온 많은 것들이 있습니다. 좁은 초점과 개발자에게 명시적인 약속을 갖는 새 정책을 만들면, 이러한 논의에는 방어 가능한 답과 사양 작성자에게 분명한 지침이 생길 것입니다.

2. 연결 허용 목록

Connection Allowlist는 주어진 컨텍스트가 연결할 수 있도록 허용된 URL 패턴 집합을 나타냅니다. 이는 다음 항목을 가진 struct입니다:

allowlist는 list인 URL patterns입니다. 달리 지정되지 않는 한 빈 목록입니다.
reporting endpoint는 null이거나 Reporting API endpoint입니다. 달리 지정되지 않는 한 null입니다.
disposition은 enforce 또는 report입니다.
redirects는 allow 또는 block입니다. 달리 지정되지 않는 한 block입니다.
webrtc는 allow 또는 block입니다. 달리 지정되지 않는 한 block입니다.

3. Connection Allowlist 헤더

Connection-Allowlist 응답 header는 컨텍스트가 연결할 수 있는 엔드포인트 집합을 정의하는 직렬화된 URL 패턴 문자열 목록을 포함합니다. 이 허용 목록은 주어진 컨텍스트에 대해 강제 적용되어, 선언된 패턴과 일치하지 않는 나가는 연결을 차단합니다. Connection-Allowlist-Report-Only 응답 header는 보고 전용 변형으로, 같은 방식으로 파싱되지만 나가는 연결을 차단하지 않고 위반 보고서만 보냅니다.

이 Connection Allowlist 헤더들은 structured headers이며, 그 값은 list인 inner lists입니다. 서버는 임의 개수의 항목이 있는 목록을 전달할 수 있지만, 첫 번째 항목만 사용됩니다. 목록의 추가 항목은 모두 무시됩니다.

inner list는 strings로 직렬화된 URL Patterns 또는 token response-origin 중 하나를 포함할 수 있습니다. 이는 response의 URL의 origin과 일치하는 패턴을 나타냅니다. 예상치 못한 값은 무시됩니다.

inner list는 임의의 parameters를 가질 수 있습니다:

report-to 매개변수의 값은 Reporting API endpoint를 나타내는 token으로 파싱됩니다 [REPORTING].
redirects 매개변수의 값은 token으로 파싱됩니다. 존재하는 경우 허용 목록의 redirects를 설정하는 데 사용됩니다. 값이 block token이면 block으로 설정되고, 그렇지 않으면 allow로 설정됩니다.
webrtc 매개변수의 값은 token으로 파싱됩니다. 존재하는 경우 허용 목록의 webrtc를 설정하는 데 사용됩니다. 값이 block token이면 block으로 설정되고, 그렇지 않으면 allow로 설정됩니다.

다른 모든 매개변수는 무시됩니다.

3.1. 파싱

response (response)가 주어졌을 때, 응답의 Connection Allowlists를 파싱하려면:

allowlists를 빈 list로 둡니다.
header를 response의 header list에서 `Connection-Allowlist`라는 이름의 list로서 구조화된 필드 값을 가져온 결과로 둡니다.
header, response의 URL, 그리고 enforce가 주어졌을 때 Connection Allowlist 헤더를 파싱합니다. 결과가 null이 아니면 이를 allowlists에 insert합니다.
header를 response의 header list에서 `Connection-Allowlist-Report-Only`라는 이름의 list로서 구조화된 필드 값을 가져온 결과로 둡니다.
header, response의 URL, 그리고 report가 주어졌을 때 Connection Allowlist 헤더를 파싱합니다. 결과가 null이 아니면 이를 allowlists에 insert합니다.
allowlists를 반환합니다.

structured header list (list), URL (response-url), 그리고 disposition (disposition)이 주어졌을 때 Connection Allowlist 헤더를 파싱하려면:

list의 size가 0이면 null을 반환합니다.
list[0]이 inner list가 아니면 null을 반환합니다.
allowlist를, 그 disposition이 disposition인 Connection Allowlist로 둡니다.
list[0]의 각 item에 대해 For each:
1. serialized pattern을 null로 둡니다.
2. item이 response-origin token인 경우:
  1. serialized pattern을 response-url의 origin의 ASCII 직렬화로 설정합니다.
3. item이 string이면 serialized pattern을 item으로 설정합니다.
4. serialized pattern이 null이면 continue합니다.
5. URL pattern을, serialized pattern가 주어지고 null을 기본 URL로 사용하여 HTTP structured field value에서 URL pattern을 빌드한 결과로 둡니다.
  
  이 단계에서 오류가 발생하면 continue합니다.
6. URL pattern을 allowlist의 allowlist에 Append합니다.
list[0]의 parameters 안의 각 key → value에 대해 For each:
1. key가 report-to이고 value가 token이면, allowlist의 reporting endpoint를 value로 설정합니다.
2. key가 redirects이고 value가 token이면:
  1. value가 "block"이면, allowlist의 redirects를 block으로 설정합니다.
  2. 그렇지 않으면, allowlist의 redirects를 allow로 설정합니다.
3. key가 webrtc이고 value가 token이면:
  1. value가 "block"이면, allowlist의 webrtc를 block으로 설정합니다.
  2. 그렇지 않으면, allowlist의 webrtc를 allow로 설정합니다.
allowlist를 반환합니다.

참고: 파싱 알고리즘에서 잘못된 입력은 모두 건너뜁니다. 파싱을 더 엄격하게 할 수도 있겠지만, 그렇게 하면 향후 유연성이 제한될 가능성이 큽니다.

3.2. 매칭

설정되는 연결의 유형에 따라, 작업할 request가 있을 수도 있고, URL만 있을 수도 있으며, 그보다 더 적은 정보만 있을 수도 있습니다. 예를 들어 dns-prefetch는 호스트에 대해서만 매칭할 수 있습니다. 아래 알고리즘들은 이러한 시나리오에서 연결 허용 목록 검사가 어떻게 동작하는지 설명합니다:

URL (url)과 connection allowlist (connection allowlist)가 주어졌을 때, URL을 Connection Allowlist에 매칭하려면 다음 단계를 실행합니다. 이 단계들은 success 또는 failure를 반환합니다.

url이 local이면 success를 반환합니다.
connection allowlist의 allowlist 안의 각 pattern에 대해 For each:
1. pattern과 url이 주어졌을 때 URL pattern matching이 null을 반환하지 않으면, success를 반환합니다.
failure를 반환합니다.

host (host)와 connection allowlist (connection allowlist)가 주어졌을 때, host를 Connection Allowlist에 매칭하려면 다음 단계를 실행합니다. 이 단계들은 success 또는 failure를 반환합니다.

connection allowlist의 allowlist 안의 각 pattern에 대해 For each:
1. input을 새 URLPatternInit 딕셔너리로 두고, 그 hostname을 pattern의 hostname component로 설정합니다.
2. host-only pattern을, input, 기본 URL로 null, 그리고 옵션으로 빈 map이 주어졌을 때 URL pattern을 생성한 결과로 둡니다.
3. synthetic url을 "https://"와 host를 연결한 값을 URL로 parsing한 결과로 둡니다.
4. host-only pattern과 synthetic url이 주어졌을 때 URL pattern matching이 null을 반환하지 않으면, success를 반환합니다.
failure를 반환합니다.

참고: hostname component만으로 새 패턴을 만들고 host에 대한 URL을 합성함으로써, 허용 목록의 _어떤_ 패턴이라도 임의의 프로토콜, 임의의 포트, 임의의 경로 등으로 해당 호스트에 대한 요청을 허용할 수 있다면 매칭을 반환할 수 있습니다.

url이 Connection Allowlists에 의해 차단되어야 하는지 알고리즘은 URL (url), environment (environment), 그리고 list인 connection allowlists (connection allowlists)를 받습니다. 이는 allowed 또는 blocked 중 하나를 반환합니다:

connection allowlists의 각 connection allowlist에 대해 For each:
1. url이 connection allowlist와 matches하면, continue합니다.
2. url, environment, 그리고 connection allowlist가 주어졌을 때 위반을 보고합니다.
3. connection allowlist의 disposition이 enforce이면, blocked를 반환합니다.
allowed를 반환합니다.

request가 Connection Allowlists에 의해 차단되어야 하는지 알고리즘은 request (request)를 받고, allowed 또는 blocked 중 하나를 반환합니다:

allowlists를 request의 policy container의 connection allowlists로 둡니다.
allowlists의 각 allowlist에 대해 For each:
1. request의 URL list의 size가 1보다 크면:
  1. allowlist의 redirects가 allow이면, continue합니다.
  2. request의 url, request의 client, 그리고 allowlist가 주어졌을 때 위반을 보고합니다.
    
    참고: 리디렉션이 차단될 때, 리디렉션 대상에 대해 필요한 것보다 더 많은 정보를 누출하지 않기 위해 의도적으로 request의 url을 보고하고 그 current url은 보고하지 않습니다.
  3. allowlist의 disposition이 enforce이면, blocked를 반환합니다.
  4. Continue합니다.
2. request의 url이 allowlist와 matches하면, continue합니다.
3. request의 url, request의 client, 그리고 allowlist가 주어졌을 때 위반을 보고합니다.
4. allowlist의 disposition이 enforce이면, blocked를 반환합니다.
allowed를 반환합니다.

host가 Connection Allowlists에 의해 차단되어야 하는지 알고리즘은 host (host), environment (environment), 그리고 list인 connection allowlists (connection allowlists)를 받습니다. 이는 allowed 또는 blocked 중 하나를 반환합니다:

connection allowlists의 각 connection allowlist에 대해 For each:
1. host가 connection allowlist와 host-matches하면, continue합니다.
2. host, environment, 그리고 connection allowlist가 주어졌을 때 위반을 보고합니다.
3. connection allowlist의 disposition이 enforce이면, blocked를 반환합니다.
allowed를 반환합니다.

WebRTC가 Connection Allowlists에 의해 차단되어야 하는지 알고리즘은 environment settings object (environment)를 받고 allowed 또는 blocked 중 하나를 반환합니다:

allowlists를 environment의 policy container의 connection allowlists로 둡니다.
allowlists의 각 allowlist에 대해 For each:
1. allowlist의 webrtc가 allow이면, continue합니다.
2. "webrtc", environment, 그리고 allowlist가 주어졌을 때 위반을 보고합니다.
3. allowlist의 disposition이 enforce이면, blocked를 반환합니다.
allowed를 반환합니다.

3.3. 보고

다른 정책 메커니즘과 마찬가지로, Connection Allowlists는 각 위반을 허용 목록 헤더에 지정된 Reporting API 엔드포인트로 보고합니다. 위반은 다음 딕셔너리 유형으로 표현됩니다:

enum ConnectionAllowlistDisposition { "enforce", "report" };

dictionary ConnectionAllowlistViolationReport : ReportBody {
  USVString url;
  USVString connection;
  sequence<DOMString> allowlist;
  ConnectionAllowlistDisposition disposition;
};

ConnectionAllowlistViolationReport의 connection은 허용 목록을 위반한 연결의 직렬화된 URL입니다.

ConnectionAllowlistViolationReport의 allowlist는 위반된 allowlist입니다.

ConnectionAllowlistViolationReport의 disposition은 allowlist의 disposition입니다.

URL 또는 string "webrtc" (resource URL), environment (environment), 그리고 connection allowlist (allowlist)가 주어졌을 때 위반을 보고하려면:

allowlist의 reporting endpoint가 null이면 반환합니다.
violation을 다음과 같이 초기화된 새 ConnectionAllowlistViolationReport로 둡니다:

url: environment의 creation URL을 보고서에 사용하기 위해 제거한 값입니다.
connection: resource URL이 URL이면, resource URL을 보고서에 사용하기 위해 제거한 값입니다.; 그렇지 않으면 resource URL입니다.
allowlist: allowlist의 allowlist 안의 각 패턴을 직렬화한 결과를 포함하는 새 목록입니다.
disposition: allowlist의 disposition입니다.

environment를 컨텍스트로, "connection-allowlist"를 유형으로, allowlist의 reporting endpoint를 대상으로, violation을 데이터로 하여 보고서를 생성하고 큐에 넣습니다.

4. 임베디드 적용

문서는 다른 서버에서 전달된 콘텐츠를 임베드하는 경우가 많으며, 임베드된 콘텐츠가 적어도 문서에서 요구하는 만큼 제한되도록 보장하려 한다. `Connection-Allowlist` 헤더를 사용하면 서버가 자체 연결을 제한할 수 있지만, 임베더는 자신이 프레임에 넣는 문서에 적용되는 연결 허용 목록을 제어할 수 없다. 이 절에서는 [csp-embedded-enforcement]을 모델로 한 옵트인 메커니즘을 정의하며, 이를 통해 임베더가 프레임에 포함된 문서에 특정 연결 허용 목록을 요구할 수 있다.

임베더는 connectionAllowlist 콘텐츠 속성을 통해 프레임에 요구하는 연결 허용 목록을 선언한다. 사용자 에이전트는 `Sec-Required-Connection-Allowlist` 요청 헤더를 통해 이 요구 사항을 프레임에 포함된 문서에 전달한다. 프레임에 포함된 문서는 요구 사항을 충족하는 `Connection-Allowlist`를 명시하거나, 임베더의 출처를 지정하는 `Allow-Connection-Allowlist-From` 응답 헤더를 반환하여 요구 사항에 옵트인한다. 로컬 스킴 (예: about:srcdoc 및 data:)에서 전달된 문서는 임베더의 정책 컨테이너를 상속하므로 암묵적으로 옵트인한다. 옵트인하지 않는 프레임은 차단된다.

프레임이 옵트인하면, 요구된 연결 허용 목록이 문서 자체에서 명시한 허용 목록과 함께 프레임에 포함된 Document의 정책 컨테이너에 추가되며, 이 요구 사항은 필수 연결 허용 목록을 통해 프레임의 자손에게 상속된다.

임베더는 위젯이 https://good.example 및 위젯 자체 출처와만 통신하도록 제한한다:

<iframe connectionAllowlist='("https://good.example" response-origin)'
        src="https://widget.example/"></iframe>

사용자 에이전트는 탐색 요청과 함께 요구 사항을 전송한다:

GET / HTTP/1.1
Host: widget.example
Sec-Required-Connection-Allowlist: ("https://good.example" response-origin)

위젯은 임베더의 출처를 승인하여 옵트인하거나...

Allow-Connection-Allowlist-From: https://embedder.example

...요구 사항을 충족하는 연결 허용 목록을 명시하여 옵트인한다:

Connection-Allowlist: ("https://good.example" response-origin)

어느 경우든 프레임은 로드되며, 그 결과 생성된 Document는 https://good.example 및 자체 출처로 제한된다. 위젯이 두 헤더 중 어느 것도 반환하지 않았고 로컬 스킴에서 전달되지도 않았다면 프레임은 차단되었을 것이다.

4.1. `connectionAllowlist` 속성

partial interface HTMLIFrameElement {
  [CEReactions] attribute DOMString connectionAllowlist;
};

connectionAllowlist 콘텐츠 속성은 임베더가 iframe으로 프레임에 넣는 Document에 요구하는 연결 허용 목록을 제공한다. 그 값은 `Connection-Allowlist` 헤더와 동일한 문법, 즉 내부 목록의 목록인 구조화된 헤더를 사용한다(§ 3 연결 허용 목록 헤더 참조).

connectionAllowlist IDL 속성은 connectionAllowlist 콘텐츠 속성을 반영해야 한다.

참고: 문서가 자체적으로 적용하는 서버 명시 `Connection-Allowlist`와 달리, connectionAllowlist 속성은 임베더가 설정하고 다른 문서에 적용한다. 임베더가 원하지 않는 교차 출처 콘텐츠에 정책을 몰래 강제하지 못하도록, 프레임에 포함된 문서는 반드시 옵트인해야 한다. § 4.4 요구 사항 가져오기 및 적용을 참조한다.

4.2. 임베디드 적용 헤더

Sec-Required-Connection-Allowlist 요청 헤더는 임베더가 프레임에 포함된 문서에 요구하는 연결 허용 목록을 전달한다. 그 값은 `Connection-Allowlist` 문법을 사용하는 구조화된 헤더 목록이다. 이름에 Sec- 접두사가 있으므로 이 헤더는 금지된 요청 헤더이며, 따라서 사용자 에이전트만 설정하고 스크립트는 설정하거나 수정할 수 없다.

Allow-Connection-Allowlist-From 응답 헤더를 사용하면 문서가 임베더에서 요구한 연결 허용 목록의 적용에 옵트인할 수 있다. 이 헤더는 Allow-CSP-From과 문법 및 비교 방식을 공유하며, Fetch가 Access-Control-Allow-Origin을 일치시키는 것과 정확히 같은 방식으로 임베더의 출처를 일치시킨다:

Allow-Connection-Allowlist-From = [=origin-or-null=] / [=wildcard=]

탐색 요청(request)에서 비롯된 연결 허용 목록을 응답(response)이 허용한다는 것은 다음 단계가 true를 반환함을 의미한다:

origin을 response의 헤더 목록에서 `Allow-Connection-Allowlist-From`을 가져온 결과로 설정한다.
origin이 `*`이면 true를 반환한다.
request로 요청 출처를 바이트 직렬화한 결과가 origin이면 true를 반환하고, 그렇지 않으면 false를 반환한다.

참고: 이는 Allow-CSP-From 및 CORS 검사를 반영한다. 헤더는 임베더의 직렬화된 요청 출처 또는 와일드카드와 바이트 단위로 비교되며, URL이나 출처로 전혀 구문 분석되지 않는다.

4.3. 허용 목록 비교

허용 목록(a)의 각 pattern에 대해 b가 pattern과 같은 URL 패턴 구조체를 포함한다면, a는 허용 목록(b)의 부분 집합이다.

구조체의 동등성은 아직 명확히 정의되지 않았다. 여기서는 동일한 직렬화된 문자열에서 생성된 두 URL 패턴을 동일한 것으로 간주한다. (whatwg/infra#710도 참조한다.) [whatwg/infra 이슈 #664]

참고: 이는 비엄격 부분 집합 관계이다. a의 모든 URL 패턴은 b에 나타나야 하지만, a와 b는 같을 수 있다. 따라서 요구 사항과 정확히 같은 내용을 명시하는 응답은 해당 요구 사항을 충족한다.

참고: 위 비교에서는 응답이 명시한 URL 패턴이 요구 사항에 존재하는지만 확인하며, 해당 패턴이 논리적으로 포함되는지를 판정하기 위한 의미론적 분석은 수행하지 않는다. 이는 의도된 것이다. 한 URL 패턴이 다른 패턴을 완전히 포괄하는지를 결정하는 것은 그 문법상 어려운 문제이며, 현재 개발자의 사용 사례에는 보수적인 집합 포함 관계만으로도 충분하다.

참고: 비교되는 허용 목록은 같은 URL을 기준으로 해석되므로, response-origin 토큰은 각각에서 동일하게 해석된다.

다음 조건이 모두 true이면 연결 허용 목록(candidate)은 연결 허용 목록(requirement)을 충족한다:

candidate의 허용 목록은 requirement의 허용 목록의 부분 집합이다.
requirement의 리디렉션이 block이면, candidate의 리디렉션도 block이다.
requirement의 webrtc가 block이면, candidate의 webrtc도 block이다.

참고: 비어 있는 candidate 허용 목록은 어떤 엔드포인트도 허용하지 않으며, 모든 허용 목록의 부분 집합이므로 리디렉션 및 WebRTC 처리 방식도 충족하는 모든 요구 사항을 충족한다.

참고: "충족한다"는 이 절 전체에서 사용하는 "적어도 그만큼 엄격한" 관계를 나타낸다. 허용 목록 비교(부분 집합이다)는 URL 패턴을 처리하며, 리디렉션 및 webrtc 처리 방식은 별도의 조건으로 처리된다.

4.4. 요구 사항 가져오기 및 적용

정책 컨테이너 구조체에 필수 연결 허용 목록 항목을 추가한다. 이 항목은 null이거나 문자열(`Connection-Allowlist` 헤더 문법으로 표현된 직렬화된 요구 사항)이며, 초기값은 null이다. 이 항목은 컨텍스트가 자신이 임베드하는 문서 및 워커에 부과하는 요구 사항을 나타낸다. 로컬 스킴 문서와 워커에는 정책 컨테이너가 그대로 복사되므로 요구 사항도 직접 상속된다. 따라서 제한된 컨텍스트는 더 관대한 자식을 임베드하여 제한에서 벗어날 수 없다.

참고: 요구 사항은 해석된 연결 허용 목록이 아닌 직렬화된 문자열로 저장된다. 이는 요구 사항이 프레임 트리를 따라 상속될 때 response-origin 토큰이 프레임에 포함된 각 응답의 URL을 기준으로 독립적으로 해석되도록 하기 위한 것이다. 임베더에서 한 번만 해석하면 response-origin이 임베더의 출처로 고정되어 자손에게 잘못 적용된다. 이는 [csp-embedded-enforcement]을 반영한 것으로, 해당 명세도 요구 사항을 정책 컨테이너에 직렬화된 형태로 저장하고 적용할 때만 구문 분석한다.

참고: 요구 사항을 Document가 아닌 정책 컨테이너에 저장하는 것은 [csp-embedded-enforcement]에서 유사한 정책 컨테이너 항목을 다루는 방식에 따른 것이며, 이로 인해 같은 메커니즘으로 워커도 제한할 수 있다.

자식 탐색 가능 항목(navigable)의 필수 연결 허용 목록을 결정하려면:

container를 navigable의 컨테이너로 설정한다.
parent required를 container의 노드 문서의 정책 컨테이너의 필수 연결 허용 목록으로 설정한다.
container가 connectionAllowlist 콘텐츠 속성을 가진 iframe 요소이고, 그 값(attribute value)이 빈 문자열이 아니며, attribute value가 parent required에 대해 유효한 connectionAllowlist 속성 값이면 attribute value를 반환한다.
parent required를 반환한다.

다음 조건이 모두 true이면 문자열(value)은 요구 사항 parent required에 대해 유효한 connectionAllowlist 속성 값이다:

value는 빈 문자열이 아니다.
value의 길이는 4096 이하이다.

참고: 4096이라는 제한은 직렬화된 요구 사항을 `Sec-Required-Connection-Allowlist` 요청 헤더로 전달할 수 있을 만큼 작게 유지하고, 프레임 트리를 따라 상속될 때 제한 없이 커지는 것을 방지하기 위한 임의의 상한이다. 정확한 값 자체는 중요하지 않다.
value는 첫 번째 항목이 내부 목록인 구조화된 헤더 목록으로 구문 분석될 수 있다.
parent required가 null이거나, value가 parent required보다 적어도 그만큼 엄격하다.

참고: 프레임은 부모에게서 상속한 요구 사항을 강화할 수는 있지만 완화할 수는 없다. connectionAllowlist 속성은 부모의 요구 사항보다 적어도 그만큼 엄격한 경우에만 적용되며, 그렇지 않으면 부모의 요구 사항이 변경되지 않은 채 상속된다. 이는 [csp-embedded-enforcement]에서 iframe csp 속성이 임베더 자체의 요구 사항에 포함되어야 한다고 규정하는 유효성 요구 사항을 반영한다.

위 비교에서, a를 구조화된 헤더 목록으로 구문 분석한 뒤 a를 사용하여 Connection Allowlist 헤더를 구문 분석해 생성된 연결 허용 목록이 같은 방식으로 b를 구문 분석해 생성된 연결 허용 목록을 충족한다면, 문자열(a)은 문자열(b)보다 적어도 그만큼 엄격하다. 이때 두 경우 모두 response-origin 토큰은 URL을 기준으로 해석하지 않고, 문자열 "response-origin"에서 만들어진 리터럴 URL 패턴으로 취급한다.

참고: 이 비교는 탐색 시점에 수행되며, response-origin을 어떤 URL에 대해서도 해석하지 않는다. 임베더의 요구 사항과 프레임 자체의 요구 사항은 나중에 각각 동일한 프레임별 응답의 URL을 기준으로 해석되므로, 여기서 토큰을 자기 자신과 같은 것으로 취급해도 타당하며 교차 출처 리디렉션으로 변경될 수 있는 URL에 의존하지 않아도 된다. 비교는 보수적이다. 속성이 부모의 요구 사항보다 구문적으로 적어도 그만큼 엄격하지 않은 프레임은 단순히 해당 요구 사항을 변경 없이 상속한다.

문자열(value), URL (response-url) 및 처리 방식(disposition)이 주어졌을 때 직렬화된 연결 허용 목록 요구 사항을 구문 분석하려면:

list를 value를 구조화된 헤더 목록으로 구문 분석한 결과로 설정한다.
list가 실패이면 null을 반환한다.
list, response-url 및 disposition이 주어졌을 때 Connection Allowlist 헤더를 구문 분석한 결과를 반환한다.

자식 탐색 가능 항목에 대한 탐색 요청(request)의 응답(response)이 Connection Allowlist 임베디드 적용에 의해 차단되어야 하는지를 결정하려면, 문자열 또는 null(requirement)이 주어졌을 때 허용됨 또는 차단됨을 반환한다:

requirement가 null이면 허용됨을 반환한다.
required를 requirement, response의 URL 및 enforce가 주어졌을 때 직렬화된 연결 허용 목록 요구 사항을 구문 분석한 결과로 설정한다.
required가 null이면 허용됨을 반환한다.

참고: 잘못된 형식의 요구 사항은 프레임을 차단하는 대신 무시된다.
response가 request에서 비롯된 연결 허용 목록을 허용한다면 허용됨을 반환한다.
header를 response의 헤더 목록에서 `Connection-Allowlist`라는 이름의 "list" 구조화된 필드 값을 가져온 결과로 설정한다.
asserted를 header, response의 URL 및 enforce가 주어졌을 때 Connection Allowlist 헤더를 구문 분석한 결과로 설정한다.
asserted가 null이 아니고 required를 충족한다면 허용됨을 반환한다.

참고: 잘못된 형식으로 명시된 `Connection-Allowlist`는 null로 구문 분석되므로 옵트인으로 취급되지 않는다.
차단됨을 반환한다.

참고: 로컬 스킴 문서 (예: about:srcdoc 및 data:)에는 응답이 없으며 이 검사를 거치지 않는다. 대신 임베더의 정책 컨테이너(저장된 요구 사항 포함)를 직접 상속한다. § 5.2 HTML과의 통합을 참조한다.

5. 몽키 패치

5.1. Fetch와의 통합

동일한 목적을 수행하는 다른 검사와 함께 Fetch § 4.1 메인 Fetch에 차단 검사를 추가하여 요청을 처리한다:

메인 Fetch에서 다음과 같이 7단계를 조정한다:

잘못된 포트로 인해 요청을 차단해야 하는지, 혼합 콘텐츠로 인해 요청 가져오기를 차단해야 하는지, 콘텐츠 보안 정책에 의해 요청을 차단해야 하는지, 연결 허용 목록에 의해 요청을 차단해야 하는지, 또는 무결성 정책 정책에 의해 요청을 차단해야 하는지가 차단됨을 반환하면, 응답을 네트워크 오류로 설정한다.

Fetch는 요청을 기반으로 하지 않는 API의 연결을 설정하는 데 사용되는 하위 수준 알고리즘도 정의한다. DNS 프리페치, Web Transport 등을 처리하기 위해 출처를 확인 및 연결 획득에 연결한다:

출처 확인에서 선택적 환경 설정 객체 environment를 허용하도록 시그니처를 업데이트한다(기본값은 null).

위의 호스트 전용 일치 알고리즘을 호출하여 패턴이 주어진 호스트에 대한 연결을 잠재적으로 허용할 수 있는지 확인한다. 허용할 수 없다면 확인에 실패한다.

environment가 null이 아닌 경우:
1. allowlists를 environment의 정책 컨테이너의 연결 허용 목록으로 둔다.
2. 호스트를 연결 허용 목록으로 차단해야 하는가를 origin의 호스트, environment 및 allowlists에 대해 실행했을 때 차단됨을 반환하면, 실패를 반환한다.

연결 획득에서 선택적 환경 설정 객체 또는 Document environment를 허용하도록 시그니처를 업데이트한다(기본값은 null):

현재 단계 2 앞에 검사를 추가한다:

environment가 null이 아닌 경우:
1. allowlists를 environment의 정책 컨테이너의 연결 허용 목록으로 둔다.
2. URL을 연결 허용 목록으로 차단해야 하는가를 url, environment 및 allowlists에 대해 실행했을 때 차단됨을 반환하면, 실패를 반환한다.

Fetch 변경 사항을 적용하려면 사용할 허용 목록과 보고에 사용할 컨텍스트를 식별할 수 있도록 저수준 알고리즘의 호출 지점에 추가 정보를 전달해야 한다. 대신 해당 호출 지점에서 직접 검사를 수행하도록 하는 편이 더 나을 수도 있다. 논리를 중앙 집중화하는 편이 더 성공적일 것 같지만, 부분적으로 접근하는 편이 더 간단할 수도 있다.

5.2. HTML과의 통합

위 내용을 HTML에 통합하기 위해 정책 컨테이너 구조체에 새로운 연결 허용 목록 항목을 추가한다. 이 항목은 목록 형태의 연결 허용 목록을 포함한다. 이 항목은 페치 응답에서 정책 컨테이너를 생성 알고리즘에 단계를 추가하여 채운다:

response와 result를 사용하여 Integrity-Policy 헤더를 구문 분석한다.
result의 연결 허용 목록을 response가 주어졌을 때 응답의 연결 허용 목록을 구문 분석한 결과로 설정한다.
result를 반환한다.

참고: 초기 응답의 정책 컨테이너가 초기 힌트 링크를 페치할 때 이미 사용되므로, 초기 힌트 통합에는 추가 변경이 필요하지 않다.

§ 4 임베디드 적용을 지원하기 위해, [csp-embedded-enforcement]이 필수 CSP에 사용하는 모델을 따른다. 즉, 임베딩 요소에서 임베더의 요구 사항을 대상 스냅숏 매개변수와 내비게이션 매개변수를 거쳐 프레임된 Document의 정책 컨테이너까지 전달한다. 구체적으로 HTML과 Fetch는 다음과 같이 패치된다:

필수 연결 허용 목록 항목을 정책 컨테이너 구조체에 추가한다(§ 4.4 요구 사항 획득 및 적용에서 정의됨).
null 또는 문자열인 필수 연결 허용 목록 항목을 대상 스냅숏 매개변수 구조체에 추가한다. HTML의 대상 스냅숏 매개변수 스냅숏 생성 알고리즘은 대상 내비게이블이 주어졌을 때 필수 연결 허용 목록 결정의 결과로 이 항목을 설정한다.
이에 대응하는 항목을 내비게이션 매개변수 구조체에 추가하며, 내비게이션, 페치하여 내비게이션 매개변수 생성 및 srcdoc 리소스에서 내비게이션 매개변수 생성 알고리즘은 대상 스냅숏 매개변수 항목에서 이 항목을 설정한다.
페치하여 내비게이션 매개변수 생성은 요청을 생성한 후, 해당 항목이 null이 아닐 때 요청의 헤더 목록에 있는 `Sec-Required-Connection-Allowlist` 헤더를 대상 스냅숏 매개변수 항목으로 설정한다.
페치 응답에서 정책 컨테이너 생성은 요구 사항을 추가 인수로 받고, result의 연결 허용 목록을 채운 후 아래의 필수 연결 허용 목록 적용 단계를 실행한다.

참고: 대상 스냅숏 매개변수에 이미 포함되는 샌드박싱 플래그와 마찬가지로, 요구 사항은 내비게이션 시점에 iframe 컨테이너에서 스냅숏으로 생성되며, 프레임된 Document가 자체적으로 시작하는 내비게이션을 포함하여 내비게이블의 모든 내비게이션에 적용된다. 따라서 이 제약은 이후의 동일한 내비게이블 내비게이션에도 적용되며, 프레임된 콘텐츠가 자체적으로 다른 곳으로 이동하여 회피할 수 없다. connectionAllowlist 콘텐츠 속성의 변경은 내비게이블의 다음 내비게이션부터 적용되며, 이는 sandbox 속성의 동작과 같다. (이는 컨테이너 자체가 시작한 내비게이션에만 영향을 주는 referrerpolicy와 다르다는 점에 유의한다.)

정책 컨테이너 (result), 문자열 또는 null (requirement), 그리고 응답 (response)이 주어졌을 때 필수 연결 허용 목록을 적용하려면:

requirement가 null이면 반환한다.
required를 requirement, response의 URL 및 enforce가 주어졌을 때 직렬화된 연결 허용 목록 요구 사항을 구문 분석한 결과로 둔다.
required가 null이면 반환한다.
result의 연결 허용 목록에 있는 연결 허용 목록 중에서 처리 방식이 enforce이고 required를 충족하는 항목이 없으면, required를 result의 연결 허용 목록에 추가한다.
result의 필수 연결 허용 목록을 requirement로 설정한다.

참고: 임베더의 연결 허용 목록은 응답이 자체적으로 선언한 항목 (`Connection-Allowlist-Report-Only`을 포함함)과 함께 result의 연결 허용 목록에 추가 항목으로 삽입된다. 해당 목록의 모든 허용 목록이 문서의 외부 요청에 적용되므로, 임베더의 요구 사항과 문서 자체의 선언이 모두 적용된다. [csp-embedded-enforcement]에 따라, 응답이 이미 요구 사항을 충족하는 허용 목록을 선언한 경우에는 요구 사항을 추가하지 않는다. 해당 선언이 이미 요구 사항을 충족하므로 추가 항목은 불필요하기 때문이다.

참고: 해결되지 않은 요구 사항을 result의 정책 컨테이너에 저장하면 이 요구 사항이 자손에게 전파된다. 각 자손은 요구 사항과 그 response-origin 토큰을 자체 응답을 기준으로 다시 해결한다. 따라서 프레임 자체에 적용되는 허용 목록이 요구 사항보다 더 엄격하더라도, 프레임은 자식에게 정책을 적용해야 한다. 로컬 스킴(예: about:srcdoc 및 data:)에서 생성된 Document의 경우 정책 컨테이너가 임베더로부터 상속되므로 요구 사항도 함께 상속된다.

차단 결정은 Fetch에서 이루어진다. 핸드셰이크에 실패한 내비게이션 응답은 네트워크 오류로 대체된다. 자식 내비게이블을 대상으로 하는 내비게이션 요청(request)에 대한 응답을 얻은 후, request와 내비게이션의 필수 연결 허용 목록이 주어졌을 때 응답이 연결 허용 목록 임베디드 적용에 의해 차단되어야 하는지 결정한 결과가 차단됨이면 사용자 에이전트는 네트워크 오류를 반환한다.

펜스드 프레임 및 해당 요청이 임베더의 정책 컨테이너에 의해 관리되지 않는 다른 컨텍스트는 이 메커니즘으로 제한할 수 없다. 이러한 컨텍스트는 임베더가 연결 허용 목록을 요구할 때 제한 없이 로드되도록 허용해서는 안 되며, 반드시 차단해야 한다. § 6.2 임베디드 적용을 참조한다.

이 통합은 의도적으로 콘텐츠 보안 정책: 임베디드 적용 § 2.4 HTML과의 통합과 유사하게 구성되었다. 두 메커니즘은 전달되는 정책 유형과 "최소한 그만큼 엄격함" 비교에서만 다르다. 이상적으로는 공유 기반 구조(대상 스냅숏 매개변수 / 내비게이션 매개변수 항목, 요청 헤더 훅 및 정책 컨테이너 적용)를 HTML 또는 공유 임베디드 정책 적용 명세로 분리하고 정책 유형을 매개변수화해야 한다. 두 명세를 단일 메커니즘으로 정렬하는 작업은 후속 작업으로 추적된다.

5.3. DNS 프리페칭

dns-prefetch 링크 유형에 대한 연결된 리소스를 페치하고 처리 단계에서 링크 요소의 노드 문서를 출처 확인에 전달한다:

HTML의 dns-prefetch 링크 유형에 대한 연결된 리소스를 페치하고 처리 단계의 단계 4를 다음과 같이 업데이트한다:

사용자 에이전트는 partitionKey, url의 출처 및 el의 관련 설정 객체가 주어졌을 때 출처를 확인해야 한다 .

5.4. 사전 연결

사전 연결 알고리즘에서 링크 옵션의 환경을 연결 획득에 전달한다:

HTML의 사전 연결 알고리즘의 단계 5를 다음과 같이 업데이트한다:

사용자 에이전트는 partitionKey, url의 출처, useCredentials 및 options의 환경이 주어졌을 때 연결을 획득해야 한다 .

5.5. WebRTC와의 통합

WebRTC 연결을 제한하기 위해 [webrtc]은 후보가 관리상 금지됨인지 결정하는 동안 WebRTC를 연결 허용 목록으로 차단해야 하는가 알고리즘을 호출할 수 있다.

5.6. 서비스 워커와의 통합

서비스 워커 자체의 정책 컨테이너를 적용하는 기본 동작 외에도, 서비스 워커는 WindowClient API를 사용하여 내비게이션을 호출할 때 자체 연결 허용 목록을 적용해야 한다.

navigate() 및 openWindow(url) 알고리즘은 모두 다음과 같이 패치해야 한다:

url, this의 관련 설정 객체 및 this의 관련 설정 객체의 정책 컨테이너의 연결 허용 목록에 대해 실행했을 때 URL을 연결 허용 목록으로 차단해야 하는가가 차단됨을 반환하면, "SecurityError" DOMException으로 거부된 프로미스를 반환한다.

navigate()는 현재 문서를 내비게이션의 sourceDocument로 전달한다. 이는 다소 누락처럼 보인다. 논의를 참조한다.

6. 보안 및 개인정보 보호 고려 사항

6.1. 동일 출처 컨텍스트

§ 1.1 위협 모델에 설명된 위협 모델은 의도적으로 범위가 좁으며, 개발자는 여기에 설명된 허용 목록 메커니즘을 방어 체계에 어떻게 계층적으로 적용할지 신중하게 고려해야 한다. 가장 중요한 점은 이 메커니즘이 출처 전체가 아니라 컨텍스트별로 적용된다는 것이다. 이로 인해 스크립팅 접근 권한을 가진 공격자가 제한이 더 적은 동일 출처 컨텍스트를 찾아 컨텍스트의 허용 목록을 우회할 가능성이 크게 남는다. HTML의 정책 컨테이너와의 통합은 이러한 가능성 중 일부를 해결하지만, 다른 가능성도 존재할 것이다. 예를 들어 공격자는 프레임 트리를 거슬러 올라가 제한이 더 적은 부모에 접근하거나, 오프너 관계를 유지하는 window.open()을 통해 새 창을 열 수 있다. 따라서 문서의 출처를 (response-origin을 통해 또는 명시적으로) 허용 목록에 추가하는 것만으로는 그 자체로 완전한 해결책이 되지 않는다.

개발자가 허용 목록이 적용된 컨텍스트를 일반적인 출처에서 분리하여 샌드박스화함으로써 이 위험을 피할 수 있는 시나리오도 있다. 이를 위해 sandbox 속성이나 콘텐츠 보안 정책의 sandbox 지시문을 사용할 수 있다. 이러한 경우 동일 출처인 문서가 없으므로 경계를 유지하기가 더 쉬워진다.

개발자는 각 프레임 문서가 스스로를 제한하도록 의존하는 대신, § 4 임베디드 적용에 설명된 임베디드 적용 메커니즘을 사용하여 프레임에 포함된 문서에 연결 허용 목록을 요구할 수도 있다.

6.2. 임베디드 적용

§ 4 임베디드 적용을 사용하면 임베더가 프레임에 포함된 문서에 연결 허용 목록을 요구할 수 있으며, 이슈 #1을 해결한다. 다음과 같은 여러 특성으로 인해 이 기능이 새로운 공격 표면이 되는 것을 방지한다:

필수 옵트인. 임베더는 원하지 않는 교차 출처 콘텐츠에 정책을 강제할 수 없다. 프레임에 포함된 문서는 요구 사항을 충족하는 `Connection-Allowlist`를 명시하거나, 임베더를 지정하는 `Allow-Connection-Allowlist-From` 헤더를 반환해야 한다. 옵트인이 없고(로컬 스킴에서 전달된 경우도 아니라면) 프레임은 차단된다. 이는 iframe csp 속성에 옵트인을 요구하게 된 우려를 반영한다. [csp-embedded-enforcement]
상속 시 완화 없음. 요구 사항은 자손 프레임에 상속되며, 자손 자체의 connectionAllowlist 속성은 상속된 요구 사항을 충족하는 경우에만 적용된다. 따라서 제한된 하위 프레임은 더 관대한 손자 프레임을 임베드하여 제한을 벗어날 수 없다. 로컬 스킴 문서에서도 상속된 허용 목록은 임베디드 적용에 의해 완화되지 않는다.
보수적 허용. 잘못된 형식으로 명시된 `Connection-Allowlist`는 null로 구문 분석되어 옵트인으로 간주되지 않으며, 엄격성 비교는 보수적인 구문적 집합 포함 검사이다. 따라서 프레임에 포함된 문서는 실제로 충족하지 않는 요구 사항을 충족한 것으로 처리될 수 없다.

요청이 임베더의 정책 컨테이너의 지배를 받지 않는 컨텍스트 (예: 펜스드 프레임)는 이 메커니즘으로 제한할 수 없다. 임베더가 해당 컨텍스트에 연결 허용 목록을 요구하는 경우, 제한 없이 로드되도록 허용하는 대신 해당 컨텍스트를 반드시 차단해야 한다.

6.3. 서비스 워커

서비스 워커는 다른 동일 출처 컨텍스트와 마찬가지로 허용 목록에 관한 문제를 복잡하게 만든다. 이들은 자신이 관리하는 각 문서와는 별개의 정책 컨테이너를 가지므로, 서비스 워커의 허용 목록과 다른 허용 목록을 가진 문서에서 시작된 메시지나 요청에 응답할 가능성이 충분히 있다. 이 제안은 다른 정책의 설계를 따르며, 이러한 기능상의 차이를 허용한다.

문서의 연결 허용 목록은 서비스 워커가 요청을 가로채기 전에 적용된다는 점에 유의하라. 따라서 요청이 문서 자체의 연결 허용 목록에 의해 차단되는 경우 서비스 워커는 해당 문서의 요청을 절대로 볼 수 없다.

그러나 서비스 워커는 여전히 문서를 대신하여 외부로 fetch 요청을 수행함으로써 문서가 자체 연결 허용 목록을 우회하도록 도울 수 있다 (예: postMessage(...)를 통해). 이러한 데이터 유출 경로로부터 보호하기 위해 개발자는 워커 스크립트와 함께 동일하게 제한적인 허용 목록을 제공할 수 있다. 이는 모든 제공되는 스크립트에 적용하는 대신 Sec-Fetch-Dest 요청 헤더가 serviceworker일 때 조건부로 `Connection-Allowlist` 헤더를 전송함으로써 효율적으로 수행할 수 있다. 서비스 워커의 경우 이 허용 목록은 워커가 처리할 수 있는 모든 문서의 허용 목록을 포함하는 상위 집합이어야 한다는 점에 유의하라.

6.4. 공유 워커

서비스 워커와 마찬가지로 공유 워커는 별개의 정책 컨테이너를 가지며 postMessage(...)를 통해 문서를 대신하여 잠재적으로 데이터 유출을 가능하게 할 수 있다. 개발자는 마찬가지로 공유 워커 스크립트와 함께 제한적인 허용 목록을 제공할 수 있다(Sec-Fetch-Dest 요청 헤더가 sharedworker인지 확인하여). blob: URL에서 생성된 공유 워커는 고유한 우회 위험을 나타낸다. data: URL 공유 워커는 시작자의 정책 컨테이너를 안전하게 상속하지만, blob: URL 공유 워커는 서로 다른 연결 허용 목록을 가진 여러 문서에서 연결될 수 있다. 이러한 문서 간 우회를 방지하기 위해 연결 허용 목록을 사용하는 개발자는 blob: URL을 제외하는 worker-src 콘텐츠 보안 정책 지시문을 지정하는 것이 권장된다.

6.5. DNS

연결 허용 목록은 DNS 조회를 통한 데이터 유출 위험을 완화하는 것을 목표로 하며, Fetch의 출처 확인 알고리즘을 변경하여 DNS 요청을 보내기 전에 허용 목록을 확인한다. 이는 요청을 보내는 요소와 API를 사용함으로써 발생하는 암시적 조회 (img 태그, fetch(), 등)뿐만 아니라 dns-prefetch와 같은 메커니즘에 의해 명시적으로 트리거되는 조회도 처리한다.

그렇지만 허용 목록은 주어진 엔드포인트가 허용 가능한지 판단하기 위해 URL 기반 일치에 의존한다. 이는 DNS 조작에 대한 방어 수단이 아니며, 요청에 관여하는 DNS 서버를 제한하지도 않는다 (DNS 확인의 재귀적 특성으로 인해 여러 서버와 통신할 가능성도 포함한다). 또한 CNAME과 같은 구성이 허용 목록 밖의 도메인에 대해 추가 조회를 일으키는 것을 제한하지도 않는다. 마찬가지로 허용 목록은 DNS가 가리키는 서버가 예상한 서버임을 보장할 수 없다.

개발자는 인증된 연결에 의존하여 DNS 하이재킹 및/또는 리바인딩의 위험을 완화해야 한다. 보안 프로토콜만 허용 목록에 포함하면 DNS를 제어하는 공격자가 트래픽을 임의의 엔드포인트로 전환하기가 훨씬 어려워진다. TLS 핸드셰이크에는 관련 이름을 가진 인증서의 소유가 필요하기 때문이다.

허용 목록의 패턴을 보안 프로토콜을 나타내는 패턴으로 제한해야 하는가? 아니면 비보안 출처에 대해서는 헤더 자체를 완전히 포기해야 하는가?

6.6. `postMessage(...)`

이 제안은 전적으로 네트워크 연결만을 다루는데, 이는 postMessage(message, options), MessageChannel, BroadcastChannel, 등과 같은 명시적인 통신 채널을 통한 통신도 포함될 것으로 예상하는 개발자에게는 의외일 수 있다. 이들 모두 허용 목록과 의미 있게 비교할 수 있는 출처 기반 모델에 부합하므로 모델을 확장하여 이들까지 포함하는 것도 타당할 수 있다.

6.7. 리디렉션

기본적으로 연결 허용 목록은 모든 리디렉션을 차단한다. 이는 오픈 리디렉션 또는 기타 서버 측 리디렉션 메커니즘을 통한 데이터 유출을 방지하기 위한 보수적인 방침이다. 문서에 허용 목록이 적용되는 경우, 리디렉션이 발생하는 모든 요청은 허용 목록이 명시적으로 이를 허용하도록 설정하지 않는 한 차단된다.

redirects 매개변수를 사용하면 개발자가 이 동작을 제어할 수 있다.

block으로 설정하면(기본값), 리디렉션 체인 길이가 1보다 큰 모든 요청이 차단된다.

allow로 설정하면 허용 목록은 초기 요청에만 적용된다. 초기 요청이 허용 목록과 일치하면 이후의 모든 리디렉션은 그 위치와 관계없이 허용된다. 이 모드는 데이터 보안에 대한 책임을 서버로 이전한다. 요청이 클라이언트에서 나가는 것이 허용된 이후에는 서버가 사용자의 데이터를 신뢰할 수 없는 위치로 리디렉션하지 않도록 보장할 책임이 있다.

이 접근 방식은 애플리케이션마다 보안 요구 사항이 다르다는 점을 인정한다. 매우 민감한 애플리케이션은 모든 리디렉션을 차단하도록 선택할 수 있으며, 다른 애플리케이션은 신뢰할 수 있는 엔드포인트가 리디렉션을 올바르게 처리하도록 의존할 수 있다.

다음 헤더가 있는 문서를 생각해 보자:

Connection-Allowlist: ("https://api.example")

https://api.example/data에 대한 요청이 https://api.example/new-data로의 302 Found 리디렉션을 반환하면 기본적으로 리디렉션이 차단되므로 차단된다.

대신 헤더가 다음과 같다면:

Connection-Allowlist: ("https://api.example");redirects=allow

https://api.example/data에 대한 동일한 요청은 허용되며, 이후의 https://api.example/new-data로의 리디렉션(또는 심지어 https://attacker.com/로의 리디렉션)도 허용된다.

마지막으로, 향후 호환성을 위해 알 수 없는 토큰은 allow로 처리된다:

Connection-Allowlist: ("https://api.example");redirects=some-future-policy

이 경우 redirects 매개변수는 존재하지만 그 값인 some-future-policy는 알 수 없는 값이다. 사용자 에이전트는 이를 allow로 처리하며 리디렉션은 허용된다. 이를 통해 기존 사이트를 손상시키지 않고 향후 추가 동작을 도입할 가능성을 열어 둘 수 있다.

6.8. WebRTC

기본적으로 연결 허용 목록은 모든 WebRTC 연결을 차단한다. 이는 URL 패턴만으로는 제한하기 어려울 수 있는 WebRTC의 고유한 네트워킹 특성을 통한 데이터 유출 위험을 완화하기 위한 보수적인 방침이다.

webrtc 매개변수를 사용하면 개발자가 이 동작을 제어할 수 있다.

block으로 설정하면(기본값), WebRTC 연결을 설정하려는 모든 시도가 차단된다.

allow로 설정하면 WebRTC 연결이 허용된다.

다음 헤더가 있는 문서를 생각해 보자:

Connection-Allowlist: ("https://api.example")

WebRTC는 기본적으로 차단되므로 WebRTC 연결을 설정하려는 모든 시도는 차단된다.