문서 정책

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

이 버전:
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. 소개

이 문서는 문서 정책을 정의합니다. 이는 웹 플랫폼의 일부로 구성 가능한 기능을 설계하고, 웹 개발자가 사이트 배포의 일부로 이러한 기능을 구성할 수 있게 하는 프레임워크입니다.

2. 예제 #

새 예제가 필요합니다. 지금은 설명 문서를 참조하십시오.

문서 정책은 문서 구성을 위한 일부 기존 메커니즘과 범위가 비슷하지만, 각각과는 중요한 차이가 있습니다.

3.1. Permissions Policy와의 관계

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

역사적으로 문서 정책은 Permissions Policy(당시에는 Feature Policy라고 불림)에 제안된 여러 기능 추가에 대한 대응으로 만들어졌습니다. 이러한 기능은 기존 'feature' 모델에 잘 맞지 않았거나, Permissions Policy 명세에 상당한 추가 복잡성을 더해야 했습니다. 여기에는 매개변수가 있는 기능, 하위 프레임으로 선택적으로 상속되는 기능, 그리고 팝업에서 다른 최상위 브라우징 컨텍스트와 다르게 상속되는 기능이 포함되었습니다.

이러한 기능은 이제 문서 정책에서 다루도록 제안되며, Permissions Policy는 위임이 주요 관심사인 기능에 사용됩니다. Permissions Policy 기능은 불리언 값(활성화 또는 비활성화)이며, 부모에서 비활성화된 경우 자식 프레임에서 다시 활성화될 수 없고, 일반적으로 "최상위 브라우징 컨텍스트와 그 동일 출처 자식에서 사용 가능하며, 교차 출처 프레임에는 위임되어야 한다"는 모델을 따릅니다.

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

3.2. Content Security Policy와의 관계

Content-Security-Policy [CSP]도 문서의 '기능'을 구성하지만, 주된 관심사는 로드된 뒤 이러한 리소스가 무엇을 할 수 있는지를 제어하는 것이 아니라, 페이지 내 리소스의 출처입니다.

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

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

3.3. 샌드박싱과의 관계

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

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

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

4. 프레임워크

4.1. 구성 지점

구성 지점은 문서 정책을 통해 활성화, 비활성화 또는 구성할 수 있는 Web Platform API 또는 동작입니다. 구성 지점은 기본 API 또는 동작을 설명하는 명세에서 정의되어야 하지만, 이 문서에는 사용 중인 정의된 구성 지점의 레지스트리가 첨부되어 있습니다.

구성 지점에는 토큰인 이름이 있습니다.

구성 지점에는 다음 중 하나인 타입이 있습니다.

  • boolean,

  • integer,

  • float, 또는

  • enum.

구성 지점에는 그 타입에 대한 모든 값의 부분집합인 범위가 있습니다.

구성 지점에는 그 범위의 원소인 기본값이 있습니다.

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

4.2. 정책

문서 정책구성 지점에서 정책 구성으로의 순서 있는 맵입니다

정책 구성구성 지점범위의 원소인 과, 문자열이며 null일 수 있는 보고 엔드포인트로 구성된 튜플입니다.

브라우징 컨텍스트에는 문서 정책필수 문서 정책이 있습니다. null인 opener browsing context를 가진 브라우징 컨텍스트는 빈 필수 문서 정책을 가집니다.

Document에는 문서 정책중첩 컨텍스트 필수 문서 정책이 있습니다.

Document에는 문서 정책문서 정책이 있습니다.

Document에는 문서 정책보고 전용 문서 정책이 있습니다.

5. 필수 정책 직렬화

  • 여기에 필수 정책이 구조화된 헤더로 어떻게 직렬화되는지 설명합니다.

  • 표준 형식이 존재하도록 보장합니다(호환성 테스트를 위해).

6. 보고

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

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

사이트는 정책을 적용하기 전에 실제 상황에서 정책을 시험해 보고자 할 수도 있습니다. 이 절은 또한 사용자 에이전트가 정책을 강제하지 않으면서도 정책 위반이 될 상황을 감시하고 보고할 수 있는 "Report-only" 모드를 정의합니다. 이를 통해 사이트 소유자는 정책을 실제로 배포하기 전에 실제 위반 수를 허용 가능한 수준까지 낮추는 작업을 할 수 있습니다.

보고는 정책을 구성한 페이지에서만 가능합니다. 필수 정책을 위반하는 중첩 페이지에서 보고서를 받을 수는 없습니다.

"위반"은 기능별로 정의되지만, 항상 사용자의 직접적인 행동이 아니라 웹 개발자의 행동을 반영해야 합니다.

이는 모든 정책을 보고할 수 있는 것은 아님을 의미합니다. 설정이 마크업이나 스크립트 동작에 의해 의미 있는 방식으로 "위반"되었다고 말할 수 없는 기능의 부류가 있습니다. 예를 들어 폼 필드의 텍스트 입력을 비활성화하는 가상의 기능은 사용자 에이전트가 강제할 수 있지만, 사용자가 해당 필드에 입력하려고 하여 강제가 필요해졌다고 해서 그것이 정책 위반을 나타내는 것은 아니며, 보고되어서는 안 됩니다.

6.1. 문서 내 보고 구성

6.1.1. "report-to" 매개변수

모든 지시자는 report-to라는 매개변수를 포함할 수 있으며, 이는 해당 기능에 대한 위반 보고서가 전송될 보고 엔드포인트의 이름을 지정합니다.

예제:

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

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

많거나 모든 기능에 대한 위반 보고서를 같은 엔드포인트로 보내야 한다면, 하나의 기본 엔드포인트를 정의하는 것이 더 쉬울 수 있습니다. 이는 특수 토큰 *의 매개변수로 정의할 수 있습니다. 기본 엔드포인트가 제공되면, 달리 지정되지 않는 한 모든 위반 보고서는 해당 이름의 엔드포인트로 전송됩니다. 어떤 기능이 report-to 매개변수로 자체 엔드포인트도 지정하면, 보고서는 대신 그 엔드포인트로 전송됩니다. (보고서는 두 엔드포인트 모두로 전송되지 않습니다.)

예제:

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

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

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

예제:

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

6.2. 보고 전용 모드

문서 정책은 "report-only" 정책일 수 있습니다. 보고 전용 정책은 Document-Policy-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 속성에서 sh-dictionary 구조의 직렬화로 표현됩니다. 각 딕셔너리 멤버는 문서 정책 지시자입니다.

문서 정책 지시자직렬화된 문서 정책의 원소이며, sh-token인 지시자 이름과 관련 매개변수로 구성됩니다.

지시자 이름은 다음 중 하나일 수 있습니다.

정책 값은 이름 지정된 구성 지점에 대한 범위의 원소입니다.

7.1.1. 매개변수

모든 문서 정책 지시자report-to라는 매개변수를 포함할 수 있으며, 그 값은 문자열이어야 합니다.

문서 정책 지시자 중 그 지시자 이름구성 지점을 명명하고, 그 타입boolean인 경우, 필요한 매개변수가 없습니다.

문서 정책 지시자 중 그 지시자 이름구성 지점을 명명하고, 그 타입integer인 경우, 필요한 매개변수가 하나 있으며, 그 값은 구성 지점범위 내의 정수여야 합니다.

문서 정책 지시자 중 그 지시자 이름구성 지점을 명명하고, 그 타입float인 경우, 필요한 매개변수가 하나 있으며, 그 값은 구성 지점범위 내의 십진수여야 합니다.

문서 정책 지시자 중 그 지시자 이름구성 지점을 명명하고, 그 타입enum인 경우, 필요한 매개변수가 하나 있으며, 그 값은 'true'여야 하고, 그 이름은 구성 지점범위 내의 토큰이어야 합니다.

예제:

7.2. HTTP 헤더

7.2.1. Document-Policy

`Document-Policy` HTTP 헤더는 클라이언트가 강제해야 하는 문서 정책을 전달하기 위해 응답(서버에서 클라이언트로)에 사용할 수 있습니다.

Document-Policy 헤더는 Structured Header입니다. 그 값은 딕셔너리여야 합니다. ABNF는 다음과 같습니다.

Document-Policy = sh-dictionary

어떤 딕셔너리 멤버 이름이 지원되는 구성 지점이나 특수 값 "*"를 명명하지 않는다면, 해당 딕셔너리 멤버는 처리 단계에서 무시됩니다.

7.2.2. Document-Policy-Report-Only

`Document-Policy-Report-Only` HTTP 헤더는 문서의 보고 전용 문서 정책을 구성하기 위해 응답(서버에서 클라이언트로)에 사용할 수 있습니다.

Document-Policy-Report-Only 헤더는 Structured Header입니다. 그 값은 딕셔너리여야 합니다. 이는 Document-Policy 헤더와 정확히 같은 구문을 가집니다.

7.2.3. Require-Document-Policy

`Require-Document-Policy` HTTP 헤더 필드는 모든 중첩 콘텐츠에 적용할 최소 필수 문서 정책을 클라이언트에 전달하는 데 사용되는 응답 헤더입니다.

Require-Document-Policy 헤더는 Structured Header 딕셔너리이며, Document-Policy 헤더와 정확히 같은 구문을 가집니다.

7.2.4. Sec-Required-Document-Policy

`Sec-Required-Document-Policy` HTTP 헤더 필드는 요청과 함께 반환되는 문서에 포함되어야 하는 문서 정책을 서버에 전달하는 데 사용되는 요청 헤더입니다.

헤더의 값은 하나 이상의 문서 정책 지시자에 대한 § 5 필수 정책 직렬화입니다

7.3. iframe 요소의 policy 속성

iframe 요소에는 필수 정책 지시자(SH 형식)를 포함하는 "policy" 속성이 있습니다.

8. 통합

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

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

8.1. HTML과의 통합

다음 변경 사항은 [HTML]에 통합되어야 합니다.

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

[CEReactions] attribute DOMString policy;

8.2. Fetch와의 통합

다음 변경 사항은 [FETCH]에 통합되어야 합니다.

9. 알고리즘

9.1. 정책이 호환되는가?

문서 정책 requiredPolicydeclaredPolicy가 주어졌을 때, 이 알고리즘은 declaredPolicyrequiredPolicy와 호환되면 true를 반환하고, 그렇지 않으면 false를 반환합니다.
  1. requiredPolicy의 각 configuration pointvalue에 대해:

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

    2. valuedeclaredPolicy[configuration point]보다 더 엄격하면, false를 반환합니다.

  2. true를 반환합니다.

9.2. 문서 정책 구문 분석

딕셔너리(header)가 주어졌을 때, 이 알고리즘은 이를 문서 정책으로 구문 분석할 수 있으면 해당 문서 정책을 반환하고, 그렇지 않으면 실패합니다.
  1. header가 null이면 null을 반환합니다.

  2. policy를 새 순서 있는 맵으로 둡니다.

  3. defaultEndpoint를 null로 설정된 새 문자열로 둡니다.

  4. header의 각 name->(value,parameters)에 대해,

    1. currentEndpoint를 null로 설정된 새 문자열로 둡니다.

    2. parameters["report-to"]가 존재하고 문자열이면:

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

    3. name이 문자열 "*"이면:

      1. defaultEndpointcurrentEndpoint로 설정합니다.

    4. 그렇지 않고, name이 지원되는 구성 지점의 이름이면:

      1. configuration point를 이름이 name인 지원되는 구성 지점으로 둡니다.

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

      3. configuration point의 타입이 boolean이면:

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

        2. policy[configuration point]를 value보고 엔드포인트 currentEndpoint를 가진 새 boolean 정책 구성으로 설정합니다.

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

      4. configuration point의 타입이 enum이면:

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

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

        3. policy[configuration point]를 value보고 엔드포인트 currentEndpoint를 가진 새 enum 정책 구성으로 설정합니다.

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

      5. configuration point의 타입이 integer이면:

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

        2. valueconfiguration point의 범위 안에 없으면 실패합니다.

        3. policy[configuration point]를 value보고 엔드포인트 currentEndpoint를 가진 새 integer 정책 구성으로 설정합니다.

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

      6. configuration point의 타입이 float이면:

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

        2. valueconfiguration point의 범위 안에 없으면 실패합니다.

        3. policy[configuration point]를 value보고 엔드포인트 currentEndpoint를 가진 새 float 정책 구성으로 설정합니다.

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

  5. policy의 각 configuration pointconfig에 대해,

    1. config보고 엔드포인트가 없으면, config보고 엔드포인트defaultEndpoint로 설정합니다.

  6. policy를 반환합니다.

9.3. 필수 정책 직렬화

문서 정책(requiredPolicy)이 주어졌을 때, 이 알고리즘은 정책의 표준 직렬화를 나타내는 문자열을 반환합니다.
  1. dict를 새 순서 있는 맵으로 둡니다.

  2. featuresrequiredPolicy의 키로 둡니다.

  3. features를 각 원소의 이름 기준 ASCII 순서로 정렬합니다.

  4. features의 각 feature에 대해:

    1. valuerequiredPolicy[feature]로 둡니다.

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

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

9.4. 브라우징 컨텍스트에 대한 필수 정책 생성

브라우징 컨텍스트(browsingContext)가 주어졌을 때, 이 알고리즘은 새 문서 정책을 반환합니다.
  1. browsingContext중첩 브라우징 컨텍스트이면,

    1. requiredPolicybrowsingContext컨테이너 문서중첩 컨텍스트 필수 문서 정책의 복제본으로 둡니다.

    2. browsingContext브라우징 컨텍스트 컨테이너에 "policy" 속성이 있으면,

      1. containerPolicy를 속성을 구문 분석한 결과로 둡니다.

      2. containerPolicy의 각 feature -> value에 대해:

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

  2. 그렇지 않으면, requiredPolicy를 새 순서 있는 맵으로 둡니다.

  3. requiredPolicy를 반환합니다.

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

브라우징 컨텍스트(browsingContext)와 응답(response)이 주어졌을 때, 이 알고리즘은 새 문서 정책을 반환합니다.
  1. requiredPolicybrowsingContext가 주어졌을 때 브라우징 컨텍스트에 대한 필수 정책 생성을 실행한 결과로 둡니다.

  2. headerresponseheader list에서 헤더 이름 Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다.

  3. declaredPolicyheader에 대해 문서 정책 구문 분석을 실행한 결과로 둡니다.

  4. declaredPolicyrequiredPolicy호환되면 declaredPolicy를 반환합니다.

  5. 예외를 throw합니다.

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

브라우징 컨텍스트(browsingContext)와 응답(response)이 주어졌을 때, 이 알고리즘은 새 문서 정책을 반환합니다.
  1. requiredPolicybrowsingContext필수 문서 정책의 복제본으로 둡니다.

  2. headerresponseheader list에서 헤더 이름 Required-Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다.

  3. declaredNestedPolicyheader에 대해 문서 정책 구문 분석을 실행한 결과로 둡니다.

  4. declaredNestedPolicy의 각 feature -> value에 대해:

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

  5. requiredPolicy를 반환합니다.

9.7. 문서 정책 때문에 요청에 대한 응답이 차단되어야 하는가?

request(request)와 그 요청에 대한 response(response)가 주어졌을 때, 이 알고리즘은 응답이 요청의 필수 정책과 호환되지 않으면 "blocked"를 반환하고, 그렇지 않으면 "valid"를 반환합니다.
  1. request필수 문서 정책이 있으면,

    1. documentPolicyresponseheader list에서 헤더 이름 Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다.

    2. documentPolicyrequest필수 문서 정책호환되지 않으면 "blocked"를 반환합니다.

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

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

기능(feature)과 Document 객체(document)가 주어졌을 때, 이 알고리즘은 document문서 정책 안에서 feature에 대한 값을 반환합니다.
  1. policydocument문서 정책으로 둡니다.

  2. policy[feature]가 존재하면, 그 을 반환합니다.

  3. feature기본값을 반환합니다.

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

값(value), 기능(feature) 및 Document 객체 (document)가 주어졌을 때, 이 알고리즘은 다음으로 구성된 튜플을 반환합니다.
  • 동작. 이는 valuedocument문서 정책과 호환되는지에 따라 "compatible" 또는 "incompatible"입니다.

  • 보고 엔드포인트 이름. valuedocument문서 정책 및 그 보고 전용 문서 정책 모두와 호환되거나, feature에 대해 보고가 구성되지 않은 경우 null이 됩니다. 그렇지 않으면 위반 보고서를 전송해야 하는 보고 엔드포인트의 이름이 됩니다.

강제 정책이 보고 전용 정책보다 더 엄격한 경우, 보고 전용 정책은 검사되지 않습니다.

  1. policydocument문서 정책으로 둡니다.

  2. policyConfigpolicy[feature]가 존재하면 그 값으로, 그렇지 않으면 feature기본값과 null로 구성된 튜플로 둡니다.

  3. policyValuereporting endpointpolicyConfig의 원소로 둡니다.

  4. policyValuevalue보다 더 엄격하면, "incompatible"과 reporting endpoint로 구성된 튜플을 반환합니다.

  5. report-only policydocument보고 전용 문서 정책으로 둡니다.

  6. report-only policyConfigreport-only policy[feature]가 존재하면 그 값으로, 그렇지 않으면 feature기본값과 null로 구성된 튜플로 둡니다.

  7. policyValuereporting endpointreport-only policyConfig의 원소로 설정합니다.

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

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

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

값(value), 기능(feature) 및 Document 객체 (document)가 주어졌을 때, 이 알고리즘은 valuedocument문서 정책과 호환되면 "compatible"을 반환하고, 그렇지 않으면 "incompatible"을 반환합니다. 보고가 구성된 경우 보고서도 큐에 넣습니다.
  1. (action, reporting endpoint)를 value, featuredocumentdetermine-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. settingsdocument환경 설정 객체로 둡니다.

    4. body, "document-policy-violation", reporting endpointsettingsReporting API § 2.3 Queue data as type for destination를 실행합니다.

  3. action을 반환합니다.

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

값(value), 기능(feature) 및 Document 객체 (document)가 주어졌을 때, 이 알고리즘은 valuedocument문서 정책과 호환되면 "compatible"을 반환하고, 그렇지 않으면 "incompatible"을 반환합니다.
  1. (action, reporting endpoint)를 value, featuredocumentdetermine-compatibility를 호출한 결과로 둡니다.

  2. action을 반환합니다.

10. IANA 고려사항

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

헤더 필드 이름
Document-Policy
적용 가능한 프로토콜
http
상태
standard
작성자/변경 관리자
W3C
명세 문서
Document Policy API
헤더 필드 이름
Require-Document-Policy
적용 가능한 프로토콜
http
상태
standard
작성자/변경 관리자
W3C
명세 문서
Document Policy API
헤더 필드 이름
Sec-Required-Document-Policy
적용 가능한 프로토콜
http
상태
standard
작성자/변경 관리자
W3C
명세 문서
Document Policy API

11. 개인정보 보호와 보안

이 명세는 삽입하는 페이지가 삽입된 페이지에 강제될 정책을 설정하는 메커니즘을 표준화합니다. 그러나 기존 sandbox iframe 메커니즘과 달리 필수 정책에 대한 명시적 승인이 필요합니다. 이는 해당 사이트의 협력 없이는 게시된 웹 사이트에서 기존 기능의 동작을 변경할 수 없음을 의미합니다.

이 모델에서는 염두에 두어야 할 몇 가지 개인정보 보호 및 보안 고려사항이 있습니다.

  • 교차 출처 하위 프레임의 동작이 그 삽입자에게 노출됨.

  • 정책을 통해 삽입자 상태가 삽입된 문서에 노출됨.

  • 필수 정책을 맹목적으로 수락함으로 인한 예상치 못한 동작 변경.

어느 정도 이러한 우려는 웹 플랫폼에 이미 존재하며, 이 명세는 적어도 이를 불필요하게 악화시키지 않으려 합니다.

개별 구성 지점의 설계로 인해 보안 및 개인정보 보호 문제가 발생할 수도 있으므로, 이 명세와 통합할 때 주의해야 합니다. 이 절은 어떤 종류의 동작이 그러한 문제를 일으킬 수 있는지에 대한 지침을 제공하려 합니다.

11.1. 교차 출처 동작의 노출

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

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

위에서 논의한 동작 변경 문제를 완화하기 위해, 필수 정책이 있는 프레임의 삽입된 콘텐츠에 대한 요청은 정책 요구사항을 자세히 설명하는 HTTP 헤더와 함께 전송됩니다. 이 헤더는 출처 서버에 보이며, 그 내용은 삽입자 페이지에 관한 세부 정보를 드러낼 수 있습니다. 삽입자는 삽입된 콘텐츠에 정책을 요구하기로 선택할 때 이 점을 알고 있어야 합니다.

11.3. 필수 정책의 맹목적 수락

삽입자가 요구한 정책을 준수해야 로드될 수 있으므로, 사이트 소유자는 웹 서버가 단순히 Sec-Required-Document-Policy 요청 헤더를 응답의 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"를 통해 규범적 텍스트와 구분됩니다. 다음과 같습니다.

참고, 이는 정보 제공 참고입니다.

적합한 알고리즘

알고리즘의 일부로 명령형으로 표현된 요구사항 (예: "strip any leading space characters" 또는 "return false and abort these steps")은 알고리즘을 도입할 때 사용된 핵심 단어 ("must", "should", "may" 등)의 의미로 해석해야 합니다.

알고리즘 또는 특정 단계로 표현된 적합성 요구사항은 최종 결과가 동등한 한 어떤 방식으로든 구현될 수 있습니다. 특히 이 명세에서 정의된 알고리즘은 이해하기 쉽도록 의도된 것이며, 성능이 뛰어나도록 의도된 것은 아닙니다. 구현자는 최적화하는 것이 권장됩니다.

색인

이 명세에서 정의하는 용어

참조로 정의되는 용어

참고 문헌

규범 참고 문헌

[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[REPORTING]
Douglas Creager; et al. Reporting API. 2018년 9월 25일. WD. URL: https://www.w3.org/TR/reporting-1/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. 2004년 9월. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864

정보 참고 문헌

[CSP]
Mike West. Content Security Policy Level 3. 2021년 6월 29일. WD. URL: https://www.w3.org/TR/CSP3/
[ECMA-262]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[PERMISSIONS-POLICY]
Ian Clelland. Permissions Policy. 2020년 7월 16일. WD. URL: https://www.w3.org/TR/permissions-policy-1/

이슈 색인

구성 지점이 여러 매개변수를 가질 수 있도록 허용해야 하는가? 아마 매개변수는 이름, 타입, 범위와 함께 별도로 정의되어야 할 수도 있습니다.