문서 정책

초안 커뮤니티 그룹 보고서,

이 버전:
https://wicg.github.io/document-policy/
이슈 추적:
GitHub
사양 내 인라인
편집자:
(Google)

초록

이 사양은 개발자가 ...할 수 있도록 하는 메커니즘을 정의합니다.

이 문서의 상태

이 사양은 Web Platform Incubator Community Group에서 게시했습니다. 이 문서는 W3C 표준이 아니며 W3C 표준 트랙에 포함되어 있지도 않습니다. W3C Community Contributor License Agreement (CLA)에 따라 제한된 옵트아웃 및 기타 조건이 적용된다는 점에 유의하시기 바랍니다. W3C Community and Business Groups에 대해 자세히 알아보시기 바랍니다.

1. 소개

이 문서는 웹 플랫폼의 일부로 구성 가능한 기능을 설계하고, 웹 개발자가 사이트 배포의 일부로 해당 기능을 구성할 수 있도록 하는 프레임워크인 Document Policy를 정의합니다.

2. 예시 #

새로운 예시가 필요합니다. 현재는 설명 자료를 참조하시기 바랍니다.

Document Policy는 문서 구성을 위한 일부 기존 메커니즘과 범위가 유사하지만, 각각과 상당한 차이점이 있습니다.

3.1. Permissions Policy와의 관계

Permissions Policy [PERMISSIONS-POLICY]는 작성자가 문서의 기능을 구성할 수 있도록 하는 또 다른 메커니즘이며, 범위는 유사하지만 다른 상속 메커니즘을 사용합니다. 이로 인해 Document Policy로 제어하기에 적합한 기능과는 별도로, 특정 유형의 기능에 더 적합합니다.

역사적으로 Document Policy는 Permissions Policy(당시에는 Feature Policy라고 불림)에 제안된 여러 기능 추가에 대한 대응으로 만들어졌습니다. 이러한 기능은 기존의 'feature' 모델에 완전히 맞지 않거나, Permissions Policy 사양에 상당한 추가 복잡성을 요구했습니다. 여기에는 매개변수가 있는 기능, 하위 프레임으로 선택적 상속되는 기능, 팝업에서 다른 최상위 탐색 컨텍스트와 다르게 상속되는 기능이 포함되었습니다.

이러한 기능은 이제 Document Policy에서 다루도록 제안되었으며, Permissions Policy는 위임이 주요 관심사인 기능에 사용됩니다. Permissions Policy 기능은 부울 값을 가지며(활성화 또는 비활성화), 부모에서 비활성화된 경우 자식 프레임에서 다시 활성화할 수 없고, 일반적으로 "최상위 탐색 컨텍스트와 동일 출처 자식에서 사용 가능하며; 교차 출처 프레임에는 위임해야 함"이라는 모델을 따릅니다.

반대로 Document Policy로 제어되는 기능은 매개변수를 가질 수 있으며, 해당 매개변수는 서로 다른 프레임에서 관련 없는 값을 가질 수 있습니다 (부모 프레임에서 기능을 제한한다고 해서 반드시 자식 프레임이 제한되는 것은 아닙니다).

3.2. Content Security Policy와의 관계

Content-Security-Policy [CSP]도 문서의 '기능'을 구성하지만, 주로 페이지의 리소스 출처에 관심을 두며, 로드된 후 해당 리소스가 수행할 수 있는 작업을 제어하는 것에는 중점을 두지 않습니다.

CSP는 또한 sandbox 지시어를 통해 문서에 샌드박스 플래그를 설정하는 다른 메커니즘을 제공합니다. 샌드박스 플래그가 문서 정책으로 이동된다면, 두 헤더가 동일한 정보를 인코딩할 수 있으므로 이는 중복될 수 있습니다.

CSP-Embedded-Enforcement는 자식 문서가 정책을 준수하도록 강제하고, Fetch 중 네트워크 오류로 비준수 문서를 거부하는 모델을 도입했습니다. 이 모델은 필수 정책 메커니즘을 위해 문서 정책에서 채택됩니다.

3.3. Sandboxing과의 관계

Iframe 샌드박싱은 문서의 기능을 제어하기 위한 또 다른 메커니즘이며, 문서 정책의 필수 정책과 매우 유사한 방식으로 동작합니다. 기능 비활성화는 프레임에 적용될 수 있으며, 해당 프레임에 로드되는 모든 콘텐츠에 영향을 줍니다.

iframe sandbox 속성으로 제어되는 기능은 문서 정책을 사용하여 매우 자연스럽게 표현할 수 있습니다.

iframe 샌드박싱과 문서 정책의 한 가지 주요 차이점은 프레임에서 'sandbox' 속성이 사용될 때 모든 샌드박스 기능이 기본적으로 적용되고, 하나씩 다시 활성화해야 한다는 점입니다. 이로 인해 새로운 기능을 추가하여 샌드박싱 모델을 확장하기가 매우 어렵습니다. 추가된 기능은 즉시 기존의 모든 샌드박스 콘텐츠에 영향을 주기 때문입니다. 또한 출처 서버가 자신의 콘텐츠가 샌드박스 처리될 것임을 알 수 있는 메커니즘이 없으므로, 샌드박스 문서의 제어 흐름을 변경할 수 있는 새로운 샌드박스 기능을 추가하기 어렵습니다. 이는 기존 콘텐츠에 새로운 보안 취약점을 도입할 수 있습니다.

4. 프레임워크

4.1. 구성 지점

configuration point는 Document Policy를 통해 활성화, 비활성화 또는 구성할 수 있는 Web Platform API 또는 동작입니다. 구성 지점은 기본 API 또는 동작을 설명하는 사양에서 정의해야 하지만, 이 문서에 연결된 사용 중인 정의된 구성 지점 레지스트리가 있습니다.

configuration point에는 name이 있으며, 이는 token입니다.

configuration point에는 type이 있으며, 다음 중 하나입니다:

  • boolean,

  • integer,

  • float, 또는

  • enum.

configuration point에는 range가 있으며, 이는 해당 type의 모든 값 중 일부 집합입니다.

configuration point에는 default value가 있으며, 이는 해당 range의 요소입니다.

구성 지점이 여러 매개변수를 가질 수 있어야 하는가? 아마도 매개변수는 이름, 유형 및 범위와 함께 별도로 정의해야 합니다.
새로운 구성 지점을 도입할 때 default value는 신중하게 선택해야 하며, 웹 호환성을 가장 중요하게 고려해야 합니다. 문서에 명시적인 정책이 선언되지 않은 경우 기본값이 적용됩니다.

4.2. 정책

document policy는 configuration points에서 policy configurations로의 정렬된 맵입니다.

policy configuration은 configuration point의 range 요소인 value와 문자열이며 null일 수 있는 reporting endpoint로 구성된 튜플입니다.

browsing context에는 required document policy가 있으며, 이는 document policy입니다. 어떤 browsing context의 opener browsing context가 null이면, 해당 browsing context는 빈 required document policy를 가집니다.

Document에는 nested context required document policy가 있으며, 이는 document policy입니다.

Document에는 document policy가 있으며, 이는 document policy입니다.

Document에는 report-only document policy가 있으며, 이는 document policy입니다.

5. 필수 정책 직렬화

  • 필수 정책이 구조화된 헤더로 직렬화되는 방법을 여기에 설명합니다.

  • 정규 형식이 존재하는지 확인합니다(호환성 테스트용).

6. 보고

문서 정책을 배포하는 사이트는 페이지에 설정된 정책 중 위반되는 정책이 있는지 알고 싶을 수 있습니다. 예를 들어 모든 이미지가 컨테이너 크기와 일치하도록 요구하는 정책을 설정한 사이트는 새 개발자나 CMS가 콘텐츠에 크기가 초과된 이미지를 삽입할 경우 알림을 받고 싶을 수 있습니다. 마찬가지로 document.write API 사용을 제한하는 정책을 배포하는 사이트는 해당 API를 사용하는 스크립트가 가져와지는 경우 보고서를 받고 싶을 수 있습니다.

이 절에서는 Reporting API를 사용하여 이러한 위반을 보고하는 메커니즘을 정의합니다. [REPORTING]

사이트는 정책을 실제 상황에서 적용하기 전에 테스트하고 싶을 수도 있습니다. 이 절에서는 사용자 에이전트가 정책 위반이 될 수 있는 상황을 감시하고 보고하지만, 정책을 적용하지 않는 "Report-only" 모드도 정의합니다. 이를 통해 사이트 소유자는 실제 정책을 배포하기 전에 실제 위반 수를 허용 가능한 수준까지 줄일 수 있습니다.

보고는 정책을 구성한 페이지에서만 가능합니다. 필수 정책을 위반하는 중첩 페이지로부터 보고서를 받는 것은 불가능합니다.

"Violation"은 기능별로 정의되지만, 항상 사용자가 직접 수행한 작업이 아니라 웹 개발자의 작업을 반영해야 합니다.

이는 모든 정책을 보고할 수 있는 것은 아니라는 의미입니다. 마크업이나 스크립트 동작으로 의미 있게 "위반"되었다고 할 수 없는 설정을 가진 기능 유형이 있습니다. 예를 들어 양식 필드의 텍스트 입력을 비활성화하는 가상의 기능은 사용자 에이전트가 강제할 수 있지만, 사용자가 해당 필드에 입력을 시도하여 강제가 필요한 상황이 발생하더라도 이는 정책 위반을 나타내지 않으며 보고되어서도 안 됩니다.

6.1. 문서 내 보고 구성

6.1.1. "report-to" 매개변수

모든 지시어는 report-to라는 이름의 매개변수를 포함할 수 있으며, 이 매개변수는 해당 기능의 위반 보고서가 전송될 보고 endpoint를 지정합니다.

예:

Document-Policy: something=1.0;report-to=endpoint1, something-else=?0;report-to=endpoint2

6.1.2. 기본 보고 엔드포인트 설정

많은 또는 모든 기능의 위반을 동일한 엔드포인트로 보내야 하는 경우, 단일 기본 endpoint를 정의하는 것이 더 쉬울 수 있습니다. 이는 특수 token *의 매개변수로 정의할 수 있습니다. 기본 endpoint가 제공되면 별도로 지정하지 않는 한 모든 위반 보고서는 해당 이름의 엔드포인트로 전송됩니다. 기능이 report-to 매개변수를 사용하여 자체 엔드포인트를 지정하는 경우 보고서는 대신 해당 엔드포인트로 전송됩니다. (보고서는 두 엔드포인트 모두로 전송되지 않습니다.)

예:

Document-Policy: something=1.0, something-else=?0, *;report-to=endpoint

6.1.3. 기능에 대한 보고 비활성화

기본 엔드포인트가 지정된 경우 특정 기능에 대한 보고를 비활성화해야 할 수 있습니다. 이는 report-to 매개변수의 값으로 특수 엔드포인트 이름 none을 지정하여 수행할 수 있습니다. 이는 기본 엔드포인트를 재정의하고 해당 기능에 대한 보고를 비활성화합니다.

예:

Document-Policy: something=1.0;report-to=none, something-else=?0,
                 *;report-to=endpoint

6.2. 보고 전용 모드

문서 정책은 "report-only" 정책일 수 있습니다. Report-only 정책은 Document-Policy-Report-Only 헤더로 지정됩니다. report-only 정책의 위반은 적용 정책과 동일하게 보고서를 생성하지만, 사용자 에이전트가 다른 작업을 수행하도록 하지는 않습니다.

Document-Policy-Report-Only

이 헤더의 지시어에는 report-to 지시어 매개변수를 사용해야 하며, 그렇지 않으면 아무 효과도 없습니다.

예:

Document-Policy-Report-Only: something=1.0;report-to=endpoint,
                             something-else=?0;report-to=endpoint2

7. 전달

7.1. 구조화된 헤더로서의 정책

정책은 HTTP 헤더와 HTML 속성에서 sf-dictionary 구조의 직렬화로 표현됩니다. 각 딕셔너리 구성원은 document policy directive입니다.

document policy directive는 serialized document policy의 요소이며, directive name으로 구성됩니다. 이는 sf-token이며, 관련 parameters를 가집니다.

directive name은 다음 중 하나일 수 있습니다:

policy value는 명명된 configuration point의 range 요소입니다.

7.1.1. 매개변수

모든 document policy directive는 report-to라는 이름의 매개변수를 포함할 수 있으며, 해당 값은 token이어야 합니다.

document policy directive의 directive name이 타입이 boolean인 configuration point를 지정하는 경우, 필수 매개변수가 없습니다.

document policy directive의 directive name이 타입이 integer인 configuration point를 지정하는 경우, 필수 매개변수가 있으며, 그 값은 configuration point의 range 내의 정수여야 합니다.

document policy directive의 directive name이 타입이 float인 configuration point를 지정하는 경우, 필수 매개변수가 있으며, 그 값은 configuration point의 range 내의 소수여야 합니다.

document policy directive의 directive name이 타입이 enum인 configuration point를 지정하는 경우, 필수 매개변수가 있으며, 그 값은 'true'여야 하고, 그 이름은 token이어야 하며 configuration point의 range 내에 있어야 합니다.

예:

  • boolean-feature

  • boolean-feature=?0

  • integer-feature=2

  • float-feature=-0.2

  • enum-feature=state

7.2. HTTP 헤더

7.2.1. Document-Policy

`Document-Policy` HTTP 헤더는 response(서버에서 클라이언트로)에서 클라이언트가 적용해야 하는 document policy를 전달하는 데 사용할 수 있습니다.

Document-Policy 헤더는 Structured Header입니다. 해당 값은 dictionary여야 합니다. ABNF는 다음과 같습니다:

Document-Policy = sf-dictionary

어떤 dictionary 구성원 이름도 지원되는 configuration point 또는 특수 값 "*"을 지정하지 않는 경우, 해당 dictionary 구성원은 처리 단계에서 무시됩니다.

7.2.2. Document-Policy-Report-Only

`Document-Policy-Report-Only` HTTP 헤더는 response(서버에서 클라이언트로)에서 문서의 report-only document policy를 구성하는 데 사용할 수 있습니다.

Document-Policy-Report-Only 헤더는 Structured Header입니다. 해당 값은 dictionary여야 합니다. Document-Policy 헤더와 정확히 동일한 구문을 가집니다.

7.2.3. Require-Document-Policy

`Require-Document-Policy` HTTP 헤더 필드는 응답 헤더이며, 모든 중첩 콘텐츠에 적용할 최소 required document policy를 클라이언트에 전달하는 데 사용됩니다.

Require-Document-Policy 헤더는 Structured Header dictionary이며, Document-Policy 헤더와 정확히 동일한 구문을 가집니다.

7.2.4. Sec-Required-Document-Policy

`Sec-Required-Document-Policy` HTTP 헤더 필드는 요청 헤더이며, 요청과 함께 반환되는 문서에 포함되어야 하는 document policy를 서버에 전달하는 데 사용됩니다.

헤더의 값은 하나 이상의 § 5 Required Policy Serialization인 document policy directive입니다.

7.3. iframe 요소의 policy 속성

iframe 요소에는 "policy" 속성이 있으며, 이는 필수 policy directive(SH 형식)를 포함합니다.

8. 통합

프레임에 필수 정책이 있는 경우, 사용자 에이전트가 문서에 적용할 정책을 서버에 알리기 위해 해당 정책은 모든 나가는 문서 요청의 요청 헤더에 포함되어야 합니다. 이를 통해 서버는 해당 정책을 준수하도록 반환되는 표현을 변경할 수 있습니다.

필수 정책 요청 헤더가 있는 경우, 응답은 호환되는 문서 정책 헤더를 포함해야 하며, 그렇지 않으면 fetch가 실패합니다.

8.1. HTML과의 통합

다음 변경 사항은 [HTML]에 포함되어야 합니다:

  • iframe 요소에는 다음 IDL이 추가되어야 합니다:

[CEReactions] attribute DOMString policy;

8.2. Fetch와의 통합

다음 변경 사항은 [FETCH]에 포함되어야 합니다:

9. 알고리즘

9.1. 정책 호환 여부 확인?

두 개의 document policy requiredPolicy와 declaredPolicy가 주어지면, 이 알고리즘은 declaredPolicy가 requiredPolicy와 호환되면 true를 반환하고, 그렇지 않으면 false를 반환합니다.
  1. requiredPolicy의 각 configuration point → value에 대해:

    1. declaredPolicy[configuration point]가 존재하지 않으면 false를 반환합니다.

    2. value가 declaredPolicy[configuration point]보다 엄격하면 false를 반환합니다.

  2. true를 반환합니다.

9.2. 문서 정책 구문 분석

dictionary(header)가 주어지면, 이 알고리즘은 이를 구문 분석할 수 있는 경우 document policy를 반환하고, 그렇지 않으면 실패합니다.
  1. header가 null이면 null을 반환합니다.

  2. policy를 새로운 정렬된 맵으로 설정합니다.

  3. defaultEndpoint를 새로운 문자열로 설정하고 null로 지정합니다.

  4. header의 각 name→(value,parameters)에 대해:

    1. currentEndpoint를 새로운 문자열로 설정하고 null로 지정합니다.

    2. parameters["report-to"]가 존재하고 token인 경우:

      1. currentEndpoint를 parameters["report-to"]의 값으로 설정합니다.

    3. name이 문자열 "*"인 경우:

      1. defaultEndpoint를 currentEndpoint로 설정합니다.

    4. 그렇지 않고 name이 지원되는 configuration point의 이름인 경우:

      1. configuration point를 이름이 name인 지원되는 configuration point로 설정합니다.

      2. policy[configuration point]가 존재하면 다음 element로 계속 진행합니다.

      3. configuration point의 type이 boolean인 경우:

        1. value가 Boolean이 아니면 실패합니다.

        2. policy[configuration point]를 새로운 boolean policy configuration으로 설정합니다. 이 설정은 value value와 reporting endpoint currentEndpoint를 가집니다.

        3. 다음 element로 계속 진행합니다.

      4. configuration point의 type이 enum인 경우:

        1. value가 Token이 아니면 실패합니다.

        2. value가 configuration point의 허용된 enum 값 중 하나의 이름이 아니면 실패합니다.

        3. policy[configuration point]를 새로운 enum policy configuration으로 설정합니다. 이 설정은 value value와 reporting endpoint currentEndpoint를 가집니다.

        4. 다음 element로 계속 진행합니다.

      5. configuration point의 type이 integer인 경우:

        1. value가 Integer가 아니면 실패합니다.

        2. value가 configuration point의 range에 없으면 실패합니다.

        3. policy[configuration point]를 새로운 integer policy configuration으로 설정합니다. 이 설정은 value value와 reporting endpoint currentEndpoint를 가집니다.

        4. 다음 element로 계속 진행합니다.

      6. configuration point의 type이 float인 경우:

        1. value가 Decimal이 아니면 실패합니다.

        2. value가 configuration point의 range에 없으면 실패합니다.

        3. policy[configuration point]를 새로운 float policy configuration으로 설정합니다. 이 설정은 value value와 reporting endpoint currentEndpoint를 가집니다.

        4. 다음 element로 계속 진행합니다.

  5. policy의 각 configuration point → config에 대해:

    1. config에 reporting endpoint가 없으면, config의 reporting endpoint를 defaultEndpoint로 설정합니다.

  6. policy를 반환합니다.

9.3. 필수 정책 직렬화

document policy (requiredPolicy)가 주어지면, 이 알고리즘은 정책의 정규 직렬화를 나타내는 문자열을 반환합니다.
  1. 새로운 정렬된 맵 dict를 생성합니다.

  2. features를 requiredPolicy의 키로 설정합니다.

  3. 각 요소의 이름을 기준으로 ASCII 순서에 따라 features를 정렬합니다.

  4. features의 각 feature에 대해:

    1. value를 requiredPolicy[feature]로 설정합니다.

    2. dict[feature]를 value로 설정합니다.

  5. dict의 직렬화를 반환합니다.

9.4. 탐색 컨텍스트에 대한 필수 정책 생성

browsing context (browsingContext)가 주어지면, 이 알고리즘은 새로운 Document Policy를 반환합니다.
  1. browsingContext가 nested browsing context인 경우:

    1. requiredPolicy를 browsingContext의 container document의 nested context required document policy의 복제본으로 설정합니다.

    2. browsingContext의 browsing context container에 "policy" 속성이 있는 경우:

      1. containerPolicy를 해당 속성을 구문 분석한 결과로 설정합니다.

      2. containerPolicy의 각 feature → value에 대해:

        1. requiredPolicy[feature]가 존재하지 않거나, value가 requiredPolicy[feature]보다 엄격한 경우, requiredPolicy[feature]를 value로 설정합니다.

  2. 그렇지 않으면 requiredPolicy를 새로운 정렬된 맵으로 설정합니다.

  3. requiredPolicy를 반환합니다.

9.5. 응답에서 문서 정책 생성

browsing context (browsingContext)와 response (response)가 주어지면, 이 알고리즘은 새로운 Document Policy를 반환합니다.
  1. requiredPolicy를 browsingContext를 주어진 Create a required policy for a browsing context 실행 결과로 설정합니다.

  2. header를 response의 header list에서 헤더 이름 Document-Policy와 유형 "dictionary"를 사용하여 get a structured field value를 호출한 결과로 설정합니다.

  3. declaredPolicy를 header에 대해 Parse document policy를 실행한 결과로 설정합니다.

  4. declaredPolicy가 requiredPolicy와 compatible이면 declaredPolicy를 반환합니다.

  5. 예외를 발생시킵니다.

9.6. 응답에서 중첩 컨텍스트 필수 문서 정책 생성

browsing context (browsingContext)와 response (response)가 주어지면, 이 알고리즘은 새로운 Document Policy를 반환합니다.
  1. requiredPolicy를 browsingContext의 required document policy의 복제본으로 설정합니다.

  2. header를 response의 header list에서 헤더 이름 Required-Document-Policy와 유형 "dictionary"를 사용하여 get a structured field value를 호출한 결과로 설정합니다.

  3. declaredNestedPolicy를 header에 대해 Parse document policy를 실행한 결과로 설정합니다.

  4. declaredNestedPolicy의 각 feature → value에 대해:

    1. requiredPolicy[feature]가 존재하지 않거나, value가 requiredPolicy[feature]보다 엄격한 경우, requiredPolicy[feature]를 value로 설정합니다.

  5. requiredPolicy를 반환합니다.

9.7. 문서 정책으로 인해 요청에 대한 응답을 차단해야 하는지 여부?

request (request)와 해당 요청에 대한 response (response)가 주어지면, 이 알고리즘은 응답이 요청의 필수 정책과 호환되지 않는 경우 "blocked"를 반환하고, 그렇지 않으면 "valid"를 반환합니다.
  1. request에 required document policy가 있는 경우:

    1. documentPolicy를 response의 header list에서 헤더 이름 Document-Policy와 유형 "dictionary"를 사용하여 get a structured field value를 호출한 결과로 설정합니다.

    2. documentPolicy가 request의 required document policy와 compatible하지 않으면 "blocked"를 반환합니다.

    3. "valid"를 반환합니다.

9.8. 문서의 기능에 대한 정책 값 가져오기

기능(feature)과 Document 객체(document)가 주어지면, 이 알고리즘은 document의 document policy에서 feature의 값을 반환합니다.
  1. policy를 document의 Document Policy로 설정합니다.

  2. policy[feature]가 존재하면 해당 value를 반환합니다.

  3. feature의 default value를 반환합니다.

9.9. 기능에 대한 정책과 값의 호환성 결정

값(value), 기능(feature) 및 Document 객체(document)가 주어지면, 이 알고리즘은 다음으로 구성된 튜플을 반환합니다:
  • value가 document의 document policy와 호환되는지에 따라 "compatible" 또는 "incompatible"인 동작

  • 보고 엔드포인트 이름. value가 document의 document policy 및 report-only document policy 모두와 호환되거나, feature에 대한 보고가 구성되지 않은 경우 null입니다. 그렇지 않으면 위반 보고서를 전송해야 하는 reporting endpoint의 이름입니다.

적용 정책이 report-only 정책보다 엄격한 경우, report-only 정책은 확인하지 않는다는 점에 유의합니다.

  1. policy를 document의 Document Policy로 설정합니다.

  2. policyConfig를 policy[feature]가 존재하면 해당 값으로, 그렇지 않으면 feature의 default value와 null로 구성된 튜플로 설정합니다.

  3. policyValue와 reporting endpoint를 policyConfig의 요소로 설정합니다.

  4. policyValue가 value보다 엄격하면, "incompatible"와 reporting endpoint로 구성된 튜플을 반환합니다.

  5. report-only policy를 document의 report-only document policy로 설정합니다.

  6. report-only policyConfig를 report-only policy[feature]가 존재하면 해당 값으로, 그렇지 않으면 feature의 default value와 null로 구성된 튜플로 설정합니다.

  7. policyValue와 reporting endpoint를 report-only policyConfig의 요소로 설정합니다.

  8. policyValue가 value보다 엄격하면, "compatible"과 reporting endpoint로 구성된 튜플을 반환합니다.

  9. ("compatible", null)을 반환합니다.

9.10. 값이 기능에 대한 정책과 호환되는지 또는 보고할지 결정

값(value), 기능(feature) 및 Document 객체(document)가 주어지면, 이 알고리즘은 value가 document의 document policy와 호환되면 "compatible"을 반환하고, 그렇지 않으면 "incompatible"을 반환합니다. 또한 보고가 구성되어 있으면 보고서를 대기열에 추가합니다.
  1. (action, reporting endpoint)를 value, feature, document를 사용하여 determine-compatibility를 호출한 결과로 설정합니다.

  2. reporting endpoint가 null이 아닌 경우:

    1. body를 다음 속성을 가진 새로운 ECMAScript 객체로 설정합니다: [ECMA-262]

      featureId

      feature의 문자열 표현.

      sourceFile

      null

      lineNumber

      null

      columnNumber

      null

      disposition

      action이 "incompatible"이면 "enforce", 그렇지 않으면 "report".

    2. 사용자 에이전트가 현재 스크립트를 실행 중이고 설정에서 소스 파일 URL, 줄 번호 및 열 번호를 추출할 수 있는 경우, body의 sourceFile, lineNumber 및 columnNumber를 그에 따라 설정합니다.

    3. settings를 document의 environment settings object로 설정합니다.

    4. Reporting API § 2.3 Queue data as type for destination를 body, "document-policy-violation", reporting endpoint 및 settings와 함께 실행합니다.

  3. action을 반환합니다.

9.11. 값이 기능에 대한 정책과 호환되는지 결정

값(value), 기능(feature) 및 Document 객체(document)가 주어지면, 이 알고리즘은 value가 document의 document policy와 호환되면 "compatible"을 반환하고, 그렇지 않으면 "incompatible"을 반환합니다.
  1. (action, reporting endpoint)를 value, feature, document를 사용하여 determine-compatibility를 호출한 결과로 설정합니다.

  2. action을 반환합니다.

10. IANA 고려 사항

영구 메시지 헤더 필드 레지스트리는 다음 등록으로 업데이트되어야 합니다 [RFC3864]:

Header field name
Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API
Header field name
Require-Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API
Header field name
Sec-Required-Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API

11. 개인정보 보호 및 보안

이 사양은 임베딩 페이지가 임베디드 페이지에 적용될 정책을 설정할 수 있도록 하는 메커니즘을 표준화합니다. 기존 iframe sandbox 메커니즘과 달리 필수 정책에 대한 명시적인 승인이 필요합니다. 이는 해당 사이트의 협력 없이는 게시된 웹 사이트에서 기존 기능의 동작을 변경할 수 없음을 의미합니다.

이 모델에는 고려해야 할 몇 가지 개인정보 보호 및 보안 관련 사항이 있습니다:

어느 정도 이러한 우려 사항은 이미 웹 플랫폼에 존재하며, 이 사양은 적어도 이러한 문제를 불필요하게 악화시키지 않도록 합니다.

개별 구성 지점의 설계로 인해 보안 및 개인정보 보호 문제가 발생할 수도 있으므로, 이 사양과 통합할 때 주의해야 합니다. 이 절에서는 이러한 문제를 일으킬 수 있는 동작 유형에 대한 지침을 제공하려고 합니다.

11.1. 교차 출처 동작 노출

구성 지점은 프레임된 문서에서 정책 위반이 다른 프레임의 문서에서 관찰되지 않도록 설계되어야 합니다. 예를 들어 정책에 의해 비활성화된 상태에서 사용될 경우 임베딩 문서에서 이벤트가 발생하도록 하는 가상의 기능은 임베디드 문서의 상태에 대한 정보를 추출하는 데 사용될 수 있습니다. 예를 들어 해당 기능이 사용자가 사이트에 로그인한 경우에만 사용되는 것으로 알려져 있다면, 임베더는 프레임에서 해당 기능을 비활성화한 다음 발생하는 이벤트를 수신하여 사용자가 로그인했는지 여부를 확인할 수 있습니다.

또한 일반적으로 문서에서 사용할 수 없는 교차 출처 리소스의 콘텐츠 정보가 정책으로 인해 노출되지 않도록 주의해야 합니다. 예를 들어 이미지 콘텐츠에는 개인 정보가 포함될 수 있으며, 세밀한 정책은 공격자가 정책의 구성 매개변수를 주의 깊게 조정하여 이미지 콘텐츠에 대한 정보를 추론할 수 있도록 할 수 있습니다. 하위 리소스의 콘텐츠에 작용하는 정책은 읽을 수 없는 리소스를 제외하거나, 리소스에 대해 추론할 수 있는 정보의 양을 제한하는 조치를 취해야 합니다.

앞서 논의한 동작 변경 문제에 대한 완화책으로, 필수 정책이 있는 프레임의 임베디드 콘텐츠 요청은 정책 요구 사항을 자세히 설명하는 HTTP 헤더와 함께 전송됩니다. 이 헤더는 출처 서버에서 볼 수 있으며, 해당 내용은 임베더 페이지에 대한 세부 정보를 노출할 수 있습니다. 임베더는 임베디드 콘텐츠에 정책을 요구할지 결정할 때 이를 고려해야 합니다.

11.3. 필수 정책의 무조건적 수락

임베더가 요구한 정책을 준수해야 로드될 수 있으므로, 사이트 소유자는 웹 서버가 응답의 Document-Policy 헤더에 Sec-Required-Document-Policy 요청 헤더를 단순히 그대로 반환하도록 구성하고 싶을 수 있습니다. 이렇게 하면 문서의 정책이 항상 요청과 호환되도록 보장되지만, 임베더가 기존 API를 비활성화하거나 동작을 변경하여 임베디드 문서 내부의 제어 흐름을 변경할 수 있는 위험에 문서를 노출할 수 있습니다. 이는 콘텐츠가 작성된 후 문서 정책 모델에 새로운 구성 지점이 추가될 때 특히 그렇습니다. 가능한 모든 새로운 동작 변경에 대비하여 문서를 미래에도 안전하게 유지하는 것은 어렵습니다.

필수 문서 정책이 있는 컨텍스트에 임베디드될 것으로 예상되는 사이트는 지원할 수 있다고 알고 있는 실제로 가장 엄격한 정책으로 정책을 설정하거나, 자신이 알고 있고 동작 변경의 잠재적 범위를 이해하는 구성 지점에 대해서만 들어오는 정책을 그대로 반환하여 이를 완화할 수 있습니다.

준수

문서 규칙

준수 요구 사항은 설명적 주장과 RFC 2119 용어를 조합하여 표현됩니다. 이 문서의 규범적 부분에서 사용되는 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”이라는 핵심 용어는 RFC 2119에 설명된 대로 해석해야 합니다. 그러나 가독성을 위해 이 사양에서는 이러한 단어가 모두 대문자로 표시되지 않습니다.

이 사양의 모든 텍스트는 비규범적이라고 명시적으로 표시된 절, 예시 및 주석을 제외하고 규범적입니다. [RFC2119]

이 사양의 예시는 “for example”이라는 단어로 시작하거나, 다음과 같이 class="example"을 사용하여 규범적 텍스트와 구분됩니다:

이는 정보 제공용 예시의 예입니다.

정보 제공용 주석은 “Note”라는 단어로 시작하며, 다음과 같이 class="note"를 사용하여 규범적 텍스트와 구분됩니다:

Note, 이는 정보 제공용 주석입니다.

색인

이 사양에서 정의한 용어

참조로 정의한 용어

참고 문헌

규범적 참고 문헌

[DOM]
Anne van Kesteren. DOM Standard. 현행 표준. URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch Standard. 현행 표준. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. 현행 표준. URL: https://html.spec.whatwg.org/multipage/
[REPORTING]
Douglas Creager; Ian Clelland; Mike West. Reporting API. URL: https://w3c.github.io/reporting/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. 현재 권장 사례. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. 2004년 9월. 현재 권장 사례. URL: https://www.rfc-editor.org/info/rfc3864/
[RFC8941]
M. Nottingham; P-H. Kamp. Structured Field Values for HTTP. 2021년 2월. 제안 표준. URL: https://httpwg.org/specs/rfc8941.html

비규범적 참고 문헌

[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
[ECMA-262]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[PERMISSIONS-POLICY]
Ian Clelland. Permissions Policy. URL: https://w3c.github.io/webappsec-permissions-policy/

이슈 색인

구성 지점이 여러 매개변수를 가질 수 있어야 하는가? 아마도 매개변수는 이름, 유형 및 범위와 함께 별도로 정의해야 합니다. ↵