1. 소개
이 문서는 문서 정책을 정의합니다. 이는 웹 플랫폼의 일부로 구성 가능한 기능을 설계하고, 웹 개발자가 사이트 배포의 일부로 이러한 기능을 구성할 수 있게 하는 프레임워크입니다.
2. 예제 #
새 예제가 필요합니다. 지금은 설명 문서를 참조하십시오.
3. 기타 및 관련 메커니즘
문서 정책은 문서 구성을 위한 일부 기존 메커니즘과 범위가 비슷하지만, 각각과는 중요한 차이가 있습니다.
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에는 문서 정책인 중첩 컨텍스트 필수 문서 정책이 있습니다.
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. 기능에 대한 보고 비활성화
기본 엔드포인트가 지정된 경우 특정 기능에 대한 보고를 비활성화해야 할 수 있습니다.
이는 특수 엔드포인트 이름 none을 report-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'여야 하고, 그 이름은
구성 지점의 범위 내의
토큰이어야 합니다.
예제:
-
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
헤더는 클라이언트가 강제해야 하는 문서
정책을
전달하기 위해 응답(서버에서 클라이언트로)에 사용할 수 있습니다.
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;
-
iframe policy 속성은 다음과 같이 정의되어야 합니다.
-
policy속성이 지정되면, 초기화될 때iframe의 중첩 브라우징 컨텍스트에 필수 문서 정책을 추가합니다. 그 값은 직렬화된 문서 정책이어야 합니다.
-
-
HTML § 3.1.1 The Document object에 다음 줄을 추가합니다.
-
새 브라우징 컨텍스트 생성 알고리즘에서:
-
단계 5 뒤에 다음 단계를 추가합니다.
-
browsingContext의 필수 문서 정책을 browsingContext에 대해 브라우징 컨텍스트에 대한 필수 정책 생성의 결과로 설정합니다.
-
-
단계 9(이제 10으로 다시 번호 매김됨)를 다음과 같이 변경합니다.
-
document를 새 Document로 둡니다. 이는 HTML 문서로 표시되며, quirks mode에 있고, 그 content type은
"text/html"이며, origin은 origin, active sandboxing flag set는 sandboxFlags, permissions policy는 permissions policy, document policy는 browsingContext의 필수 문서 정책과 동일하며, post-load task를 수행할 준비가 되어 있고 즉시 완전히 로드됩니다.
-
-
-
navigate fetch 처리 알고리즘에서:
-
문서 객체 초기화 알고리즘에서:
-
단계 3 뒤에 다음 단계를 추가합니다.
-
documentPolicy를 response에서 browsingContext에 대한 문서 정책 생성의 결과로 둡니다.
-
nestedContextRequiredDocumentPolicy를 response에서 browsingContext에 대한 중첩 컨텍스트 문서 정책 생성의 결과로 둡니다.
-
-
단계 6(이제 8로 다시 번호 매김됨)을 다음과 같이 변경합니다.
-
document를 새 Document로 둡니다. 그 type은 type, content type은 contentType, origin은 origin, permissions policy는 permissionsPolicy, active sandboxing flag set은 finalSandboxFlags, document policy는 documentPolicy, nested context required document policy는 nestedContextRequiredDocumentPolicy입니다.
-
-
8.2. Fetch와의 통합
다음 변경 사항은 [FETCH]에 통합되어야 합니다.
-
Fetch Standard § 2.2.5 Requests에 다음을 추가합니다.
-
Fetch Standard § 4.6 HTTP-network-or-cache fetch에서 단계 15 뒤에 다음을 삽입합니다.
-
httpRequest에 필수 문서 정책이 있으면,
-
serializedRequiredPolicy를 httpRequest의 필수 문서 정책에 대해 Serialize Required Policy를 호출한 결과로 둡니다.
-
httpRequest의 header list에
Sec-Required-Document-Policy/serializedRequiredPolicy를 추가합니다.
-
-
-
Fetch Standard § 4.1 Main fetch에서 단계 11의 알고리즘 목록에 다음 알고리즘을 추가합니다.
9. 알고리즘
9.1. 정책이 호환되는가?
-
requiredPolicy의 각 configuration point → value에 대해:
-
declaredPolicy[configuration point]가 존재하지 않으면 false를 반환합니다.
-
value가 declaredPolicy[configuration point]보다 더 엄격하면, false를 반환합니다.
-
-
true를 반환합니다.
9.2. 문서 정책 구문 분석
-
header가 null이면 null을 반환합니다.
-
policy를 새 순서 있는 맵으로 둡니다.
-
defaultEndpoint를 null로 설정된 새 문자열로 둡니다.
-
header의 각 name->(value,parameters)에 대해,
-
currentEndpoint를 null로 설정된 새 문자열로 둡니다.
-
parameters["report-to"]가 존재하고 문자열이면:
-
currentEndpoint를 parameters["report-to"]의 값으로 설정합니다.
-
-
name이 문자열 "
*"이면:-
defaultEndpoint를 currentEndpoint로 설정합니다.
-
-
그렇지 않고, name이 지원되는 구성 지점의 이름이면:
-
configuration point를 이름이 name인 지원되는 구성 지점으로 둡니다.
-
policy[configuration point]가 존재하면, 다음 element로 계속합니다.
-
configuration point의 타입이 boolean이면:
-
configuration point의 타입이 enum이면:
-
configuration point의 타입이 integer이면:
-
configuration point의 타입이 float이면:
-
-
-
policy의 각 configuration point → config에 대해,
-
policy를 반환합니다.
9.3. 필수 정책 직렬화
-
dict를 새 순서 있는 맵으로 둡니다.
-
features를 requiredPolicy의 키로 둡니다.
-
features를 각 원소의 이름 기준 ASCII 순서로 정렬합니다.
-
features의 각 feature에 대해:
-
value를 requiredPolicy[feature]로 둡니다.
-
dict[feature]를 value로 설정합니다.
-
-
dict의 직렬화를 반환합니다.
9.4. 브라우징 컨텍스트에 대한 필수 정책 생성
-
browsingContext가 중첩 브라우징 컨텍스트이면,
-
requiredPolicy를 browsingContext의 컨테이너 문서의 중첩 컨텍스트 필수 문서 정책의 복제본으로 둡니다.
-
browsingContext의 브라우징 컨텍스트 컨테이너에 "policy" 속성이 있으면,
-
containerPolicy를 속성을 구문 분석한 결과로 둡니다.
-
containerPolicy의 각 feature -> value에 대해:
-
requiredPolicy[feature]가 존재하지 않거나 value가 requiredPolicy[feature]보다 더 엄격하면, requiredPolicy[feature]를 value로 설정합니다.
-
-
-
-
그렇지 않으면, requiredPolicy를 새 순서 있는 맵으로 둡니다.
-
requiredPolicy를 반환합니다.
9.5. 응답에서 문서 정책 생성
-
requiredPolicy를 browsingContext가 주어졌을 때 브라우징 컨텍스트에 대한 필수 정책 생성을 실행한 결과로 둡니다.
-
header를 response의 header list에서 헤더 이름
Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다. -
declaredPolicy를 header에 대해 문서 정책 구문 분석을 실행한 결과로 둡니다.
-
declaredPolicy가 requiredPolicy와 호환되면 declaredPolicy를 반환합니다.
-
예외를 throw합니다.
9.6. 응답에서 중첩 컨텍스트 필수 문서 정책 생성
-
requiredPolicy를 browsingContext의 필수 문서 정책의 복제본으로 둡니다.
-
header를 response의 header list에서 헤더 이름
Required-Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다. -
declaredNestedPolicy를 header에 대해 문서 정책 구문 분석을 실행한 결과로 둡니다.
-
declaredNestedPolicy의 각 feature -> value에 대해:
-
requiredPolicy[feature]가 존재하지 않거나 value가 requiredPolicy[feature]보다 더 엄격하면, requiredPolicy[feature]를 value로 설정합니다.
-
-
requiredPolicy를 반환합니다.
9.7. 문서 정책 때문에 요청에 대한 응답이 차단되어야 하는가?
-
request에 필수 문서 정책이 있으면,
-
documentPolicy를 response의 header list에서 헤더 이름
Document-Policy와 타입 "dictionary"로 구조화된 필드 값 가져오기를 호출한 결과로 둡니다. -
documentPolicy가 request의 필수 문서 정책과 호환되지 않으면 "blocked"를 반환합니다.
-
"valid"를 반환합니다.
-
9.8. 문서 내 기능에 대한 정책 값 가져오기
9.9. 기능에 대한 정책과 값의 호환성 결정
Document
객체
(document)가 주어졌을 때, 이 알고리즘은 다음으로 구성된 튜플을 반환합니다.
-
동작. 이는 value가 document의 문서 정책과 호환되는지에 따라 "compatible" 또는 "incompatible"입니다.
-
보고 엔드포인트 이름. value가 document의 문서 정책 및 그 보고 전용 문서 정책 모두와 호환되거나, feature에 대해 보고가 구성되지 않은 경우 null이 됩니다. 그렇지 않으면 위반 보고서를 전송해야 하는 보고 엔드포인트의 이름이 됩니다.
강제 정책이 보고 전용 정책보다 더 엄격한 경우, 보고 전용 정책은 검사되지 않습니다.
-
policy를 document의 문서 정책으로 둡니다.
-
policyConfig를 policy[feature]가 존재하면 그 값으로, 그렇지 않으면 feature의 기본값과 null로 구성된 튜플로 둡니다.
-
policyValue와 reporting endpoint를 policyConfig의 원소로 둡니다.
-
policyValue가 value보다 더 엄격하면, "incompatible"과 reporting endpoint로 구성된 튜플을 반환합니다.
-
report-only policy를 document의 보고 전용 문서 정책으로 둡니다.
-
report-only policyConfig를 report-only policy[feature]가 존재하면 그 값으로, 그렇지 않으면 feature의 기본값과 null로 구성된 튜플로 둡니다.
-
policyValue와 reporting endpoint를 report-only policyConfig의 원소로 설정합니다.
-
policyValue가 value보다 더 엄격하면, "compatible"과 reporting endpoint로 구성된 튜플을 반환합니다.
-
("compatible", null)을 반환합니다.
9.10. 기능에 대한 값이 정책과 호환되는지 또는 보고해야 하는지 결정
Document
객체
(document)가 주어졌을 때, 이 알고리즘은 value가
document의 문서 정책과 호환되면 "compatible"을 반환하고,
그렇지 않으면 "incompatible"을 반환합니다. 보고가 구성된 경우 보고서도 큐에 넣습니다.
-
(action, reporting endpoint)를 value, feature 및 document로 determine-compatibility를 호출한 결과로 둡니다.
-
reporting endpoint가 null이 아니면,
-
body를 다음 속성을 가진 새 ECMAScript 객체로 둡니다. [ECMA-262]
- featureId
-
feature의 문자열 표현.
- sourceFile
-
null
- lineNumber
-
null
- columnNumber
-
null
- disposition
-
action이 "incompatible"이면 "enforce", 그렇지 않으면 "report".
-
사용자 에이전트가 현재 스크립트를 실행 중이고 설정에서 소스 파일의 URL, 줄 번호 및 열 번호를 추출할 수 있으면, body의 sourceFile, lineNumber 및 columnNumber를 그에 맞게 설정합니다.
-
settings를 document의 환경 설정 객체로 둡니다.
-
body, "document-policy-violation", reporting endpoint 및 settings로 Reporting API § 2.3 Queue data as type for destination를 실행합니다.
-
-
action을 반환합니다.
9.11. 기능에 대한 값이 정책과 호환되는지 결정
Document
객체
(document)가 주어졌을 때, 이 알고리즘은 value가
document의 문서 정책과 호환되면 "compatible"을 반환하고,
그렇지 않으면 "incompatible"을 반환합니다.
-
(action, reporting endpoint)를 value, feature 및 document로 determine-compatibility를 호출한 결과로 둡니다.
-
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. 교차 출처 동작의 노출
구성 지점은 프레임된 문서에서 정책 위반이 발생하더라도 다른 프레임의 문서가 이를 관찰할 수 없도록 설계되어야 합니다. 예를 들어 정책에 의해 비활성화된 상태에서 사용될 경우 삽입 문서에서 이벤트가 발생하도록 하는 가상의 기능은 삽입된 문서의 상태에 관한 정보를 추출하는 데 사용될 수 있습니다. 예를 들어 그 기능이 사용자가 사이트에 로그인했을 때에만 사용되는 것으로 알려져 있다면, 삽입자는 해당 프레임에서 그 기능을 비활성화한 뒤 결과 이벤트를 수신하여 사용자가 로그인했는지 여부를 판단할 수 있습니다.
또한 교차 출처 리소스의 콘텐츠에 관한 정보(일반적으로 문서에 제공되지 않는 정보)가 정책에 의해 보이게 되지 않도록 주의해야 합니다. 예를 들어 이미지 콘텐츠에는 개인 정보가 포함될 수 있으며, 세분화된 정책은 공격자가 정책의 구성 매개변수를 신중하게 조정하여 이미지 콘텐츠에 관한 무언가를 추론할 수 있게 할 수 있습니다. 하위 리소스의 콘텐츠에 작용하는 정책은 읽을 수 없는 리소스를 제외하거나, 리소스에 대해 추론할 수 있는 정보의 양을 제한하는 조치를 취해야 합니다.
11.2. 필수 정책의 광고
위에서 논의한 동작 변경 문제를 완화하기 위해, 필수 정책이 있는 프레임의 삽입된 콘텐츠에 대한 요청은 정책 요구사항을 자세히 설명하는 HTTP 헤더와 함께 전송됩니다. 이 헤더는 출처 서버에 보이며, 그 내용은 삽입자 페이지에 관한 세부 정보를 드러낼 수 있습니다. 삽입자는 삽입된 콘텐츠에 정책을 요구하기로 선택할 때 이 점을 알고 있어야 합니다.
11.3. 필수 정책의 맹목적 수락
삽입자가 요구한 정책을 준수해야 로드될 수 있으므로, 사이트 소유자는 웹 서버가 단순히
Sec-Required-Document-Policy 요청 헤더를 응답의
Document-Policy 헤더로 그대로 되돌리도록 구성하고 싶은 유혹을 받을 수
있습니다. 이렇게 하면 문서의 정책이 항상 요청과 호환되도록 보장하지만, 삽입자가
기존 API의 동작을 비활성화하거나 변경하여 삽입된 문서 내부의 제어 흐름을 바꿀 수
있는 위험에 문서를 노출할 수 있습니다. 이는 콘텐츠가 작성된 뒤 문서 정책 모델에 새
구성 지점이 추가될수록 특히 더 그렇습니다. 가능한 모든 새 동작 변경에 대해 문서를
미래에도 안전하게 만드는 것은 어렵습니다.
필수 문서 정책이 있는 컨텍스트에 삽입될 것으로 예상하는 사이트는, 자신이 지원할 수 있음을 알고 있는 실제 가장 엄격한 정책으로 정책을 설정하거나, 자신이 알고 있으며 동작 변경의 잠재적 범위를 이해하는 구성 지점에 대해서만 들어오는 정책을 되돌려 줌으로써 이를 완화할 수 있습니다.