트러스티드 타입(Trusted Types)

1. 소개

이 절은 규범적이지 않습니다.

웹 애플리케이션이 공격자가 제어하는 소스(예: 문서 URL 매개변수 또는 postMessage 채널)에서 값을 가져와 적절히 새니타이징하지 않고 인젝션 싱크, 즉 강력한 기능을 갖춘 다양한 Web API 함수 중 하나에 해당 값을 전달할 때 특정 종류의 취약점이 발생합니다.

이러한 유형의 문제는 전통적으로 방지하기 어렵습니다. 애플리케이션은 작성자가 이를 인지하지 못한 채 공격자가 제어하는 값으로 이러한 인젝션 싱크를 호출하는 경우가 흔합니다. 이는 인젝션 싱크를 호출할 때 입력이 공격자에 의해 제어되었는지 명확하지 않기 때문입니다. JavaScript의 동적인 특성으로 인해 주어진 프로그램에 그러한 패턴이 존재하지 않는지 확인하기도 어렵습니다. 이는 수동 코드 검토와 자동 코드 분석에서 자주 누락됩니다. 예를 들어 aString에 신뢰할 수 없는 데이터가 포함되어 있다면 foo[bar] = aString은 foo와 bar의 값에 따라 잠재적으로 취약점을 유발할 수 있는 문입니다.

이 문서는 공격자가 제어하는 데이터가 § 2.1.1 DOM XSS 인젝션 싱크에 도달하여 궁극적으로 공격자가 제어하는 스크립트 페이로드가 실행될 때 발생하는 DOM 기반 교차 사이트 스크립팅을 방지하는 데 중점을 둡니다. DOM XSS는 웹 애플리케이션에 60개가 넘는 서로 다른 인젝션 싱크(예: Element.innerHTML 또는 Location.href 설정자)가 있으므로 널리 발생합니다.

이 문서는 애플리케이션이 인젝션 싱크를 잠가 문자열 대신 위조할 수 없는 타입이 지정된 값만 허용할 수 있게 하는 API인 신뢰할 수 있는 타입을 정의합니다. 이러한 값은 다시 애플리케이션이 정의한 정책에서만 생성할 수 있으므로 작성자는 위험한 API를 보호하는 규칙을 정의하여 공격 표면을 웹 애플리케이션 코드베이스의 작고 격리된 부분으로 줄일 수 있으며, 이는 보호, 모니터링 및 검토가 훨씬 쉽습니다.

1.1. 목표

• 신뢰할 수 없는 데이터로 강력한 Web API를 호출할 때 발생하는 클라이언트 측 취약점의 가능성을 최소화합니다. 예를 들어 DOM XSS의 가능성을 최소화합니다.

• 보안 결정이 애플리케이션의 작은 부분에 캡슐화되는 설계를 장려합니다.

• 복잡한 웹 애플리케이션 코드베이스의 보안 검토 범위를 줄입니다.

• 일반적인 프로그래밍 오류가 감지되어 개발자에게 표시되는 방식과 유사하게 동적 및 정적 분석 도구의 도움을 받아 사용성을 유지하면서 취약점을 감지할 수 있게 합니다.

1.2. 비목표

• 서버 측에서 생성된 마크업, 특히 문서에서 실행되는 스크립트 본문으로의 리플렉션에 대한 인젝션 결과를 방지하거나 완화하지 않습니다. 서버 측 XSS 벡터를 처리하려면 기존 템플릿 시스템 또는 CSP script-src와 같은 솔루션을 권장합니다.

• 예를 들어 데이터 유출을 방지하거나 [Fetch]를 통해 외부 소스에 연결하는 것을 방지하는 등의 리소스 제한은 다루지 않습니다.

• 하위 리소스 로딩을 제어하지 않습니다. 신뢰할 수 있는 타입은 작성자가 현재 문서를 스크립팅할 수 있는 리소스의 로딩을 제어할 수 있게 하는 것을 목표로 하지만 다른 하위 리소스는 대상으로 하지 않습니다.

• 교차 출처 JavaScript 실행을 방지하지 않습니다(예를 들어 신뢰할 수 있는 타입은 data: URL을 통한 JavaScript 코드가 포함된 새 문서의 로딩을 보호하지 않습니다).

• 웹 애플리케이션의 JavaScript 코드의 악의적인 작성자가 제한을 우회할 수 없도록 방지하지 않습니다. 악의적인 작성자로부터 보호하려고 하면 지나치게 복잡하고 비실용적인 설계가 됩니다.

1.3. 사용 사례

• 작성자가 안전한 템플릿 시스템을 사용하여 UI 구성 요소를 생성하는 프레임워크로 작성된 복잡한 웹 애플리케이션을 유지 관리합니다. 애플리케이션은 보조 작업(예: 분석, 성능 모니터링)을 수행하는 타사 클라이언트 측 라이브러리에도 의존합니다. 이러한 구성 요소가 DOM XSS 취약점을 도입하지 않도록 작성자는 템플릿 라이브러리에 신뢰할 수 있는 타입 정책을 정의하고 § 2.1.1 DOM XSS 인젝션 싱크에 대한 강제 적용을 활성화합니다.

• 웹사이트가 § 2.1.1 DOM XSS 인젝션 싱크를 사용합니다. 웹사이트 개발자는 신뢰할 수 있는 타입을 추가하고 Content-Security-Policy-Report-Only 헤더 필드를 사용하여 위반을 모니터링합니다. 안전한 메서드만 사용하도록 코드를 리팩터링하여 위반을 반복적으로 수정합니다. 이후에는 더 이상 § 2.1.1 DOM XSS 인젝션 싱크가 호출되지 않습니다. 따라서 더 이상 신뢰할 수 있는 타입이 필요하지 않습니다. 개발자는 보고 전용 모드를 끄고 trusted-types 및 require-trusted-types-for 지시문을 사용하여 신뢰할 수 있는 타입 정책을 비활성화합니다. 리팩터링 중에도 웹사이트의 기능은 전혀 손상되지 않았습니다.

• 대규모 팀이 복잡한 클라이언트 측 애플리케이션을 유지 관리합니다. 팀은 애플리케이션의 보안 요구 사항을 충족하는 여러 신뢰할 수 있는 타입 정책을 생성합니다. 팀은 정책 구현과 이를 사용하는 안전한 추상화를 소수의 철저하게 검토되는 파일에 통합하고, 이러한 파일에 영향을 주는 커밋에 추가 승인을 요구합니다.

  인젝션 싱크에 영향을 주기 위해 신뢰할 수 있는 값을 생성해야 한다는 점과 정책 코드에 영향을 주는 변경 사항에 대한 추가 검토가 결합되어 개발자가 임시 문자열 조합 코드를 작성하는 대신 안전한 추상화를 사용하도록 유도합니다. § 2.1.1 DOM XSS 인젝션 싱크와 상호작용할 때 특히 그렇습니다.

  DOM XSS 위험을 고려할 때 보안 감사자는 작은 공격 표면을 확인합니다. CSP 헤더를 구성하고 안전한 추상화를 제공하는 소량의 코드에 집중하고 대부분의 클라이언트 측 애플리케이션 코드는 무시합니다.

• 기존 웹 애플리케이션은 대부분 XSS에 안전한 패턴을 사용하여 DOM과 상호작용합니다(즉, § 2.1.1 DOM XSS 인젝션 싱크를 사용하지 않습니다). 하지만 일부 위치에서는 JSONP를 사용하여 추가 스크립트를 로드하거나 innerHTML 또는 eval을 호출하는 등의 위험한 패턴을 사용합니다.

  검토 결과 이러한 위치가 XSS를 유발하지 않는 것으로 확인되었지만(예: 사용자가 제어하는 데이터가 해당 싱크 입력의 일부가 아니기 때문), 애플리케이션에서 이러한 패턴을 제거하도록 마이그레이션하기는 어렵습니다.

  따라서 이 애플리케이션에는 CSP를 강제 적용할 수 없습니다( 'unsafe-eval' 'unsafe-inline'을 사용하는 안전하지 않은 버전을 사용하지 않는 한). 또한 DOM XSS 결함이 있는 일부 코드베이스가 검토에 포함되지 않았을 가능성이 있거나 향후 도입될 수 있습니다.

  이 위험을 해결하기 위해 작성자는 검토된 부분을 신뢰할 수 있는 타입을 사용하도록 변환하고 신뢰할 수 있는 타입 강제 적용을 활성화합니다. 향후 존재할 수 있는 인젝션 싱크를 사용하는 추가 위치는 올바르게 차단되고 보고됩니다.

• 보안 팀은 클라이언트 측 비중이 큰 애플리케이션 코드에 XSS 취약점이 없는지 보장하는 업무를 맡습니다. 서버 측 코드가 동질적이고(대부분 API 백엔드이며), 애플리케이션이 신뢰할 수 있는 타입을 강제 적용하므로 검토는 신뢰할 수 있는 타입 정책과 그 규칙에만 집중합니다. 이후 검토된 정책 이름은 'trusted-types' CSP 지시문에서 허용되어 개발자가 안전하게 사용할 수 있습니다.

  자주 변경되는 종속성의 코드를 포함한 추가 코드는 신뢰할 수 있는 타입 정책을 생성하지 않는 한 검토에서 제외할 수 있습니다. 그러한 정책 없이는 코드가 DOM XSS를 유발할 수 없습니다.

2. 프레임워크

2.1. 인젝션 싱크

이 절은 규범적이지 않습니다.

인젝션 싱크는 신뢰할 수 있고 검증되었거나 적절히 새니타이징된 입력으로만 호출해야 하는 강력한 Web API 함수입니다. 공격자가 제어하는(즉, 주입된) 입력으로 인젝션 싱크를 호출하면 바람직하지 않은 결과가 발생하며 보안 취약점으로 간주됩니다.

참고: 이 문서에서 다루는 인젝션 싱크의 정확한 목록은 다음에 정의되어 있습니다. § 4 통합.

주어진 애플리케이션에 그러한 취약점이 포함되어 있는지(예: DOM XSS에 취약한지) 인젝션 싱크 호출만 분석하여 판단하기는 어렵습니다. 입력(대개 문자열)에는 출처에 대한 정보가 포함되지 않기 때문입니다. 예를 들어 애플리케이션이 동적으로 생성된 입력으로 eval()을 의도적으로 호출할 수 있지만(예: 코드 난독화를 위해), 공격자가 제공한 문자열에 eval()을 호출하는 것은 분명한 보안 취약점이지만 둘을 구별하기는 쉽지 않습니다.

이 문서는 주어진 그룹의 싱크가 가진 기능에 따라 인젝션 싱크를 그룹으로 구성합니다. 그룹에 대한 강제 적용은 trusted-types-sink-group 값으로 제어됩니다.

2.1.1. DOM XSS 인젝션 싱크

이 절은 규범적이지 않습니다.

DOM XSS 인젝션 싱크는 입력 문자열 값을 해당 값이 신뢰할 수 없을 경우 DOM XSS를 초래할 수 있는 방식으로 평가합니다.

예시는 다음과 같습니다.

• Element 속성 중 로드할 코드의 URL을 허용하는 속성의 설정자, 예를 들어 HTMLScriptElement.src,

• Element 속성 중 실행할 코드를 허용하는 속성의 설정자, 예를 들어 HTMLScriptElement.text,

• eval처럼 코드를 직접 실행하는 함수,

• 'javascript:' URL로의 내비게이션.

HTML 파서는 스크립트를 포함한 임의의 요소를 생성하고 임의의 속성을 설정할 수 있으므로 DOM XSS 인젝션 싱크에는 HTML 파싱 싱크도 포함됩니다.

• 다음과 같이 HTML 문자열을 파싱하여 문서에 삽입하는 함수: Element.innerHTML, ShadowRoot.innerHTML, 및 Element.outerHTML 설정자 또는 Document.write.

• 호출자가 제어하는 Document를 새 동일 출처 문서로 생성하는 마크업을 받는 parseFromString()과 같은 함수.

DOM XSS 인젝션 싱크 보호는 trusted-types-sink-group 중 'script'라는 이름의 값으로 제어됩니다.

2.2. 신뢰할 수 있는 타입

작성자가 인젝션 싱크에 도달하는 값을 제어할 수 있도록 § 2.2 신뢰할 수 있는 타입을 도입합니다. 다음 신뢰할 수 있는 타입 목록은 주어진 값이 특정 컨텍스트에서 인젝션 싱크와 함께 사용해도 된다고 작성자가 신뢰한다는 것을 나타냅니다.

참고: 이 컨텍스트에서 신뢰할 수 있음은 애플리케이션 작성자가 주어진 값을 인젝션 싱크와 함께 안전하게 사용할 수 있다고 확신한다는 사실을 의미하며, 해당 값이 취약점을 도입하지 않는다고 신뢰합니다. 그렇다고 해서 그 값이 실제로 안전하다는 의미는 아닙니다.

참고: 이를 통해 작성자는 주어진 값을 생성할 때 의도를 지정할 수 있으며 사용자 에이전트는 그러한 값의 타입에 따라 검사를 도입하여 작성자의 의도를 보존할 수 있습니다. 예를 들어 작성자가 값을 HTML 조각으로 사용하려는 경우 해당 값에서 스크립트를 로드하려는 시도는 실패합니다.

참고: 모든 신뢰할 수 있는 타입은 객체가 생성될 때 지정되는 변경 불가능한 문자열을 래핑합니다. 이러한 객체는 주어진 객체의 내부 문자열 값을 교체할 수 있는 JavaScript에 노출된 방법이 없다는 의미에서 위조할 수 없습니다. 이는 설정자가 노출되지 않은 내부 슬롯에 저장됩니다.

참고: 모든 신뢰할 수 있는 타입의 문자열 변환기는 내부 문자열 값을 반환합니다. 따라서 애플리케이션 코드를 DOM 문자열 대신 신뢰할 수 있는 타입을 사용하도록 점진적으로 마이그레이션하기 쉽습니다( 애플리케이션 일부에서 타입 생성을 시작하면서 코드베이스의 다른 부분에서는 계속 문자열을 사용하고 허용할 수 있습니다). 그런 의미에서 신뢰할 수 있는 타입은 일반 DOM API와 하위 호환됩니다.

2.2.1. TrustedHTML

TrustedHTML 인터페이스는 개발자가 HTML로 렌더링할 인젝션 싱크에 안심하고 삽입할 수 있는 문자열을 나타냅니다. 이러한 객체는 변경 불가능한 문자열 래퍼이며 TrustedTypePolicy의 createHTML 메서드를 통해 생성됩니다.

[Exposed=(Window,Worker)]
interface TrustedHTML {
  stringifier;
  DOMString toJSON();
};

TrustedHTML 객체에는 연결된 문자열 데이터가 있습니다. 값은 객체가 생성될 때 설정되며 수명 동안 절대 변경되지 않습니다.

toJSON() 메서드 단계와 TrustedHTML 객체의 문자열 변환 동작 단계는 연결된 데이터 값을 반환하는 것입니다.

2.2.2. TrustedScript

TrustedScript 인터페이스는 컴파일되지 않은 스크립트 본문을 가진 문자열을 나타내며 개발자는 해당 스크립트를 실행하게 될 수 있는 인젝션 싱크에 이를 안심하고 전달할 수 있습니다. 이러한 객체는 변경 불가능한 문자열 래퍼이며 TrustedTypePolicy의 createScript 메서드를 통해 생성됩니다.

[Exposed=(Window,Worker)]
interface TrustedScript {
  stringifier;
  DOMString toJSON();
};

TrustedScript 객체에는 연결된 문자열 데이터가 있습니다. 값은 객체가 생성될 때 설정되며 수명 동안 절대 변경되지 않습니다.

toJSON() 메서드 단계와 TrustedScript 객체의 문자열 변환 동작 단계는 연결된 데이터 값을 반환하는 것입니다.

2.2.3. TrustedScriptURL

TrustedScriptURL 인터페이스는 개발자가 외부 스크립트 리소스의 URL로 파싱할 인젝션 싱크에 안심하고 전달할 수 있는 문자열을 나타냅니다. 이러한 객체는 변경 불가능한 문자열 래퍼이며 TrustedTypePolicy의 createScriptURL 메서드를 통해 생성됩니다.

[Exposed=(Window,Worker)]
interface TrustedScriptURL {
  stringifier;
  USVString toJSON();
};

TrustedScriptURL 객체에는 연결된 문자열 데이터가 있습니다. 값은 객체가 생성될 때 설정되며 수명 동안 절대 변경되지 않습니다.

toJSON() 메서드 단계와 TrustedScriptURL 객체의 문자열 변환 동작 단계는 연결된 데이터 값을 반환하는 것입니다.

2.2.4. TrustedHTMLParserOptions

TrustedHTMLParserOptions 인터페이스는 개발자가 HTML을 파싱하는 인젝션 싱크에 안심하고 전달할 수 있는 옵션을 나타냅니다. 이러한 객체는 SetHTMLUnsafeOptions 사전을 둘러싼 변경 불가능한 래퍼이며 TrustedTypePolicy의 createParserOptions 메서드를 통해 생성됩니다.

[Exposed=Window]
interface TrustedHTMLParserOptions {
};

TrustedHTMLParserOptions 객체에는 연결된 불리언 runScripts 및 연결된 SanitizerConfig-또는-null 새니타이저 구성이 있습니다. 이러한 값은 객체가 생성될 때 설정되며 수명 동안 절대 변경되지 않습니다.

2.3. 정책

신뢰할 수 있는 타입은 문자열을 주어진 신뢰할 수 있는 타입 객체로 변환하는 규칙을 정의하는 사용자 정의 불변 정책을 통해서만 생성할 수 있습니다. 정책을 통해 작성자는 신뢰할 수 있는 타입이 준수해야 하는 사용자 정의 프로그래밍 규칙을 지정할 수 있습니다.

const sanitizingPolicy = trustedTypes.createPolicy('sanitize-html', {
  createHTML: (input) => myTrustedSanitizer(input, { superSafe: 'ok'}),
});

myDiv.innerHTML = sanitizingPolicy.createHTML(untrustedValue);

참고: 신뢰할 수 있는 타입 객체는 작성자가 명시적으로 신뢰한 값을 래핑합니다. 따라서 신뢰할 수 있는 타입 객체 인스턴스를 생성하는 것은 사실상 인젝션 싱크가 되므로 신뢰할 수 있는 타입 인스턴스를 생성하는 코드는 보안상 중요합니다. 신뢰할 수 있는 타입 객체 생성을 엄격히 제어할 수 있도록 생성자를 직접 노출하지 않고 작성자가 정책을 통해 생성하도록 요구합니다.

주어진 Realm에서 여러 정책을 생성할 수 있으므로 애플리케이션은 코드베이스의 서로 다른 부분에 대해 서로 다른 규칙을 정의할 수 있습니다.

const cdnScriptsPolicy = trustedTypes.createPolicy('cdn-scripts', {
  createScriptURL(url) {
    const parsed = new URL(url, document.baseURI);
    if (parsed.origin == 'https://mycdn.example') {
      return url;
    }
    throw new TypeError('invalid URL');
  },
});

myLibrary.init({policy: cdnScriptsPolicy});

참고: 신뢰할 수 있는 타입 객체는 정책을 통해서만 생성할 수 있습니다. 만약 강제 적용이 활성화되어 있으면 정책 코드만 인젝션 싱크의 동작을 트리거할 수 있으므로 정책의 create* 함수 호출 지점은 전체 프로그램에서 인젝션 싱크의 동작과 관련하여 유일한 보안 민감 코드입니다. 일반적으로 전체 코드베이스에서 작은 이 부분만 보안 검토하면 되며 인젝션 싱크 자체를 모니터링하거나 검토할 필요가 없습니다. 사용자 에이전트가 강제 하여 이러한 싱크가 일치하는 신뢰할 수 있는 타입 객체만 허용하도록 하고, 이러한 객체는 정책을 통해서만 생성할 수 있기 때문입니다.

createPolicy 함수는 정책 규칙을 적용한 후 create* 함수가 신뢰할 수 있는 타입 객체를 생성하는 정책 객체를 반환합니다.

참고: 입력을 새니타이징하는 정책은 애플리케이션 어디에서든 자유롭게 사용해도 안전하지만, 내부에서 사용하고 작성자가 제어하는 입력으로만 호출되는 느슨한 정책을 만들어야 할 수도 있습니다. 예를 들어 클라이언트 측 HTML 템플릿 라이브러리, HTML 새니타이저 라이브러리 또는 JS 비동기 코드 플러그인 로딩 하위 시스템은 각각 HTML 또는 URL을 완전히 제어해야 할 가능성이 높습니다. API 설계는 이를 지원합니다. 각 정책은 호출 지점이 정책에 대한 참조(createPolicy()의 반환 값)를 얻을 수 있는 경우에만 사용할 수 있습니다. 따라서 정책 참조는 기능으로 취급할 수 있으며 이에 대한 접근은 JavaScript 기법 (예: 클로저, 내부 함수 변수 또는 모듈)을 사용하여 제어할 수 있습니다.

(async function renderFootnote() {
  const unsafePolicy = trustedTypes.createPolicy('html', {
    createHTML: input => input,
  });
  const footnoteContent = await fetch('/footnote.html').then(r => r.text());
  footNote.innerHTML = unsafePolicy.createHTML(footnoteContent);
})();

2.3.1. 새니타이저와 함께 사용하기

신뢰할 수 있는 타입은 사용자 정의 새니타이저를 사용할 수 있도록 구성되어 있지만 createParserOptions는 내장 새니타이저 API 사용을 강제하는 방법으로도 사용할 수 있습니다.

(async function renderFootnote() {
  const footnoteContent = await fetch('/footnote.html').then(r => r.text());
  const policy = trustedTypes.createPolicy('html', {
    createParserOptions: options => {
      const sanitizer = new Sanitizer(options.sanitizer?.get() ?? {});
      sanitizer.removeUnsafe();
      return {
        sanitizer,
      };
    }
  });
  footNote.setHTMLUnsafe(footnoteContent, policy.createParserOptions({}));
})();

참고: 마크업을 파싱하는 HTML 인젝션 싱크(예: setHTMLUnsafe() 또는 innerHTML)에 신뢰할 수 있는 타입을 강제 적용할 때 TrustedHTMLParserOptions 객체(createParserOptions 에서 얻거나 기본 정책이 제공)를 사용하면 원시 문자열을 직접 파싱할 수 있으며 createHTML 또는 TrustedHTML 인스턴스가 필요하지 않습니다. 정책 작성자는 일반적으로 createParserOptions에서 새니타이저를 구성하여 신뢰할 수 없는 마크업이 파싱 중 새니타이징되도록 합니다. 파서 옵션을 지원하지 않는 문자열 전용 인젝션 싱크 (예: srcdoc 또는 document.write())나 XML 문서의 경우 원시 문자열은 여전히 createHTML을 통해 변환해야 합니다.

2.3.2. TrustedTypePolicyFactory

TrustedTypePolicyFactory는 정책을 생성하고 신뢰할 수 있는 타입 객체 인스턴스가 정책 중 하나를 통해 생성되었는지 확인합니다.

참고: 이 팩토리 객체는 JavaScript에 전역 객체의 trustedTypes 속성을 통해 노출됩니다. § 4.1.1 WindowOrWorkerGlobalScope 인터페이스 확장을 참조하십시오.

[Exposed=(Window,Worker)] interface TrustedTypePolicyFactory {
    TrustedTypePolicy createPolicy(
        DOMString policyName, optional TrustedTypePolicyOptions policyOptions = {});
    boolean isHTML(any value);
    boolean isScript(any value);
    boolean isScriptURL(any value);
    readonly attribute TrustedHTML emptyHTML;
    readonly attribute TrustedScript emptyScript;
    DOMString? getAttributeType(
        DOMString tagName,
        DOMString attribute,
        optional DOMString? elementNs = "",
        optional DOMString? attrNs = "");
    DOMString? getPropertyType(
        DOMString tagName,
        DOMString property,
        optional DOMString? elementNs = "");
    readonly attribute TrustedTypePolicy? defaultPolicy;
};

TrustedTypePolicyFactory 객체에는 연결된 TrustedTypePolicy 기본 정책이 있습니다. 그 값은 처음에 null입니다.

TrustedTypePolicyFactory 객체에는 연결된 문자열의 순서 있는 집합 생성된 정책 이름이 있습니다. 그 값은 처음에 « »입니다.

anElement.innerHTML = trustedTypes.emptyHTML; // 정책을 생성할 필요가 없습니다.

// 네이티브 신뢰할 수 있는 타입을 지원하면 eval(trustedTypes.emptyScript)가 실행되고 falsy undefined를 반환합니다.
// 지원하지 않으면 eval(trustedTypes.emptyScript)가 truthy Object를 반환합니다.
const supportsTS = !eval(trustedTypes.emptyScript);

eval(supportsTS ? myTrustedScriptObj : myTrustedScriptObj.toString());

trustedTypes.defaultPolicy === null;  // true
const dp = trustedTypes.createPolicy('default', {});
trustedTypes.defaultPolicy === dp;  // true

2.3.3. TrustedTypePolicy

정책 객체는 TrustedTypePolicy 인터페이스를 구현하며 신뢰할 수 있는 타입 객체를 생성하는 함수 그룹을 정의합니다. 각 create* 함수는 문자열 값을 주어진 신뢰할 수 있는 타입 변형으로 변환하거나 주어진 값의 변환이 허용되지 않으면 TypeError를 발생시킵니다.

[Exposed=(Window,Worker)]
interface TrustedTypePolicy {
  readonly attribute DOMString name;
  TrustedHTML createHTML(DOMString input, any... arguments);
  TrustedScript createScript(DOMString input, any... arguments);
  TrustedScriptURL createScriptURL(DOMString input, any... arguments);
  [Exposed=Window] TrustedHTMLParserOptions createParserOptions(optional SetHTMLUnsafeOptions options = {}, any... arguments);
};

각 정책에는 이름이 있습니다.

각 TrustedTypePolicy 객체에는 연결된 TrustedTypePolicyOptions 옵션 객체가 있으며, 정책의 실제 동작을 설명합니다.

2.3.4. TrustedTypePolicyOptions

이 사전은 문자열 값을 신뢰할 수 있는 값으로 변환하기 위한 작성자 정의 함수를 보관합니다. 이 함수들은 신뢰할 수 있는 타입 객체 인스턴스를 직접 생성하지 않으며, 이 동작은 TrustedTypePolicy가 제공합니다.

dictionary TrustedTypePolicyOptions {
   CreateHTMLCallback createHTML;
   CreateScriptCallback createScript;
   CreateScriptURLCallback createScriptURL;
   CreateParserOptionsCallback createParserOptions;
};
callback CreateHTMLCallback = DOMString? (DOMString input, any... arguments);
callback CreateScriptCallback = DOMString? (DOMString input, any... arguments);
callback CreateScriptURLCallback = USVString? (DOMString input, any... arguments);
callback CreateParserOptionsCallback = SetHTMLUnsafeOptions? (SetHTMLUnsafeOptions options, any... arguments);

2.3.5. 기본 정책

이 절은 규범적이지 않습니다.

정책 중 하나인 이름이 "default"인 정책은 특별합니다. 인젝션 싱크에 신뢰할 수 있는 타입 객체 대신 문자열이 전달되면 이 정책은 사용자 에이전트에 의해 신뢰할 수 없는 문자열 값, 싱크의 신뢰할 수 있는 타입 및 싱크 타입과 함께 각각 암시적으로 호출됩니다.

이를 통해 애플리케이션은 위반을 발생시키는 대신 사용할 폴백 동작을 정의할 수 있습니다. 의도는 애플리케이션이 예상치 못한 데이터 흐름에서 복구하고 잠재적으로 공격자가 제어하는 문자열을 "최후의 수단으로" 새니타이징하거나 안전한 값을 생성할 수 없는 경우 값을 거부할 수 있게 하는 것입니다. 정책 내부에서 발생한 오류는 애플리케이션에 전파됩니다.

기본 정책이 존재하지 않거나 적절한 create* 함수가 null 또는 undefined를 반환하면 CSP 위반이 발생합니다. 강제 적용 모드에서는 오류가 발생하지만 보고 전용 모드에서는 기본 정책에 전달된 원래 값이 사용됩니다.

참고: 이 선택적 동작을 통해 아직 인젝션 싱크를 사용하는 레거시 코드가 있는 애플리케이션에 신뢰할 수 있는 타입 강제 적용을 도입할 수 있습니다. 말할 필요도 없이 이 정책은 애플리케이션의 알 수 없는 부분에서 보안 제한을 우회하지 않도록 매우 엄격한 규칙으로 정의해야 합니다. 극단적인 경우 느슨한 무연산 기본 정책은 신뢰할 수 있는 타입을 사용하는 모든 이점을 무효화하여 인젝션 싱크에 대한 접근을 보호하지 못하게 합니다. 가능하다면 작성자는 과도기 동안에만 기본 정책을 사용하고 이를 사용해 인젝션 싱크를 안전하지 않게 사용하는 종속성을 감지하고 다시 작성한 다음 최종적으로 기본 정책 사용을 완전히 단계적으로 제거해야 합니다.

참고: § 3.5 신뢰할 수 있는 타입 준수 문자열 가져오기에서 기본 정책이 적용되는 방법에 대한 자세한 내용을 참조하십시오.

// Content-Security-Policy: trusted-types default; require-trusted-types-for 'script'

trustedTypes.createPolicy('default', {
  createScriptURL: (value, type, sink) => {
    console.log("Please refactor.");
    return value + '?default-policy-used&type=' + encodeURIComponent(type) +
          '&sink=' + encodeURIComponent(sink);
  }
});

aScriptElement.src = "https://cdn.example/script.js";
// 리팩터링하십시오.
console.log(aScriptElement.src);
// https://cdn.example/script.js?default-policy-used&type=TrustedScriptURL&sink=HTMLScriptElement%20src

2.4. 강제 적용

참고: 강제 적용은 값이 인젝션 싱크에 도달하기 전에 적절한 타입인지 확인하는 과정입니다.

작성자가 정책과 그로부터 신뢰할 수 있는 타입 객체를 생성할 수 있게 하는 JavaScript API는 항상 사용할 수 있습니다(trustedTypes를 통해). 인젝션 싱크는 보안에 민감한 인수를 문자열화하고 신뢰할 수 있는 타입 객체는 내부 문자열 값으로 문자열화되므로 작성자는 문자열 대신 신뢰할 수 있는 타입을 사용할 수 있습니다.

인젝션 싱크에 대한 접근을 보호하려면 신뢰할 수 있는 타입을 사용하는 JavaScript 코드에 더해 사용자 에이전트가 이를 강제 적용해야 합니다. 즉, 주어진 그룹의 인젝션 싱크가 문자열 값으로 절대 호출되지 않고 대신 신뢰할 수 있는 타입 값이 사용되는지 확인해야 합니다. 이 절에서는 작성자가 이 강제 적용 동작을 제어할 수 있는 방법을 설명합니다.

작성자는 정책 생성에 관한 규칙을 지정하여 정책도 제어할 수 있습니다.

2.4.1. 콘텐츠 보안 정책

애플리케이션은 콘텐츠 보안 정책을 구성하여 신뢰할 수 있는 타입 강제 적용을 제어할 수 있습니다. 이 문서는 신뢰할 수 있는 타입 규칙에 대응하는 새 지시문을 정의합니다. require-trusted-types-for 지시문은 타입이 요구되어야 하는 인젝션 싱크 그룹을 지정합니다. trusted-types 지시문은 정책을 생성할 수 있는 방법을 제어합니다.

참고: CSP 메커니즘을 사용하면 작성자는 신뢰할 수 있는 타입을 강제 적용하도록 애플리케이션을 준비할 수 있으며 Content-Security-Policy-Report-Only HTTP 응답 헤더를 사용할 수 있습니다.

참고: 대부분의 강제 적용 규칙은 다른 명세의 알고리즘 수정으로 정의되어 있습니다. § 4 통합을 참조하십시오.

2.4.2. createParserOptions를 통한 새니타이징 강제 적용

createHTML은 JS 새니타이저를 사용하여 문자열이 파서에 주입되기 전에 새니타이징하는 데 의존하지만 createParserOptions는 페이지의 기본 정책이 HTML 새니타이징을 강제할 수 있게 합니다.

기본 정책의 createParserOptions 콜백은 HTML 조각 싱크가 검토되지 않은 파서 옵션(또는 기본 옵션)으로 호출될 때마다 실행되므로 정책이 호출자가 제공한 옵션을 검토하고 입력 마크업이 이미 TrustedHTML 인스턴스인 경우에도 새니타이징을 강제할 수 있습니다.

Content-Security-Policy: require-trusted-types-for 'script'

(async function renderFootnote() {
  trustedTypes.createPolicy('default', {
    createParserOptions: options => {
      const sanitizer = new Sanitizer(options.sanitizer?.get() ?? {});
      sanitizer.removeUnsafe();
      return { ...options, sanitizer };
    }
  });

  const trustedOptions = trustedTypes.createPolicy('trusted', {
    createParserOptions: options => options
  }).createParserOptions({});
  const untrustedFootnoteContent = await fetch('/footnote.html').then(r => r.text());

  // 기본 정책이 안전하지 않은 마크업을 제거한 새니타이저를 주입하므로 이 HTML은 "안전한" HTML 새니타이저로 새니타이징됩니다.
  // 안전하지 않은 마크업이 제거된 새니타이저입니다.
  footNote.innerHTML = untrustedFootnoteContent;
  // 또는:
  footNote.setHTMLUnsafe(untrustedFootnoteContent, {});
  const trustedMainContent = await fetch("main.html").then(r => r.text());
  main.setHTMLUnsafe(trustedMainContent, trustedOptions);
})();

(async function renderFootnote() {
  trustedTypes.createPolicy('default', {
    createHTML: string => string,
    createParserOptions: options => {
      return { ...options, runScripts: false };
    }
  });

  // 기본 정책은 runScripts 값을 false로 재정의합니다.
  main.setHTMLUnsafe(someHTMLWithScripts, {runScripts: true});

  // 이는 Range.prototype.createContextualFragment()에도 적용됩니다.
  const fragment = new Range().createContextualFragment("<script>alert(1)</" + "script>");
  const div = document.createElement('div');
  // 기본 정책이 runScripts를 재정의하므로 조각의 스크립트는 실행되지 않습니다.
  div.appendChild(fragment);
})();

2.4.3. 입력 강제 적용 요약

이 절은 규범적이지 않습니다.

다음 표는 신뢰할 수 있는 타입 준수 입력 가져오기의 동작을 강제 적용 콘텐츠 보안 정책에서 다양한 인수와 기본 정책 콜백 조합에 대해 요약합니다.

TrustedHTML, runScripts 및 새니타이징: 신뢰할 수 있는 타입을 강제 적용하는 싱크는 옵션과 스크립트를 다음과 같이 처리합니다.

• input이 TrustedHTML 인스턴스인 경우에도 기본 정책의 createParserOptions는 호출자가 제공한 옵션 사전을 계속 검토하므로 정책이 새니타이저 구성을 검사, 구성 또는 재정의하고 스크립트 실행도 제어할 수 있으며, 입력이 이미 TrustedHTML이어도 마찬가지입니다. createParserOptions가 예외를 발생시키거나 null 또는 undefined를 반환하면 작업이 거부됩니다. createParserOptions가 없으면 검토가 필요한 작성자 제공 옵션 사전은 input이 TrustedHTML 인스턴스이든 createHTML로 변환된 문자열이든 거부됩니다. createContextualFragment()의 runScripts를 true로 설정하는 경우처럼 싱크가 자체적으로 생성하는 옵션은 거부되지 않습니다.
• options가 TrustedHTMLParserOptions이면 스크립트 실행과 새니타이징은 옵션 객체를 생성한 정책에 의해 결정됩니다. 옵션이 사전으로 전달되면 기본 정책의 createParserOptions가 최종 스크립트 실행 동작을 결정하여 호출자가 요청한 runScripts 설정을 재정의합니다.
• XML 조각 파싱은 새니타이징을 지원하지 않으며 모든 새니타이저 구성은 XML 싱크에서 무시됩니다.
• 스트리밍 HTML 조각 파싱에서는 신뢰할 수 있는 타입 준수 파서 옵션 가져오기가 throwIfMissing을 true로 설정하여 직접 호출됩니다. 이 컨텍스트에서 createParserOptions가 없거나, 예외를 발생시키거나, null 또는 undefined를 반환하면 TypeError가 즉시 발생하거나 다시 발생합니다.

3. 알고리즘

3.1. 신뢰할 수 있는 타입 정책 생성

신뢰할 수 있는 타입 정책을 생성하려면, TrustedTypePolicyFactory (factory), 문자열(policyName), TrustedTypePolicyOptions 사전(options) 및 전역 객체(global)가 주어지면 다음 단계를 실행합니다.

1. allowedByCSP를 신뢰할 수 있는 타입 정책 생성을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘을 global, policyName 및 factory의 생성된 정책 이름 값으로 실행한 결과로 둡니다.

2. allowedByCSP가 "Blocked"이면 TypeError를 발생시키고 이후 단계를 중단합니다.

3. policyName이 default이고 factory의 기본 정책 값이 null이 아니면 TypeError를 발생시키고 이후 단계를 중단합니다.

4. policy를 새로운 TrustedTypePolicy 객체로 둡니다.

5. policy의 name 속성 값을 policyName으로 설정합니다.

6. policy의 옵션 값을 «[ "createHTML" -> options["createHTML"], "createScript" -> options["createScript"], "createScriptURL" -> options["createScriptURL"], "createParserOptions" -> options["createParserOptions"] ]»로 설정합니다.

7. policyName이 default이면 factory의 기본 정책 값을 policy으로 설정합니다.

8. policyName을 factory의 생성된 정책 이름에 추가합니다.

9. policy을 반환합니다.

3.2. 신뢰할 수 있는 타입 생성

TrustedTypePolicy policy, 타입 이름 trustedTypeName, 문자열 또는 사전 value 및 목록 arguments가 주어졌을 때 신뢰할 수 있는 타입을 생성하려면 다음 단계를 수행합니다.

1. policyValue를 신뢰할 수 있는 타입 정책 값 가져오기를 이 알고리즘과 동일한 인수 및 추가로 true를 throwIfMissing으로 하여 실행한 결과로 둡니다.

2. 알고리즘에서 오류가 발생하면 오류를 다시 발생시키고 이후 단계를 중단합니다.

3. trustedTypeName이 "TrustedHTMLParserOptions"이면:

   1. policyValue가 null이면 TypeError를 발생시킵니다.

      참고: 이름이 지정된 정책의 createParserOptions 콜백에서 null을 반환하면 여기서 TypeError가 발생하는 반면, createHTML, createScript 또는 createScriptURL에서 null 또는 undefined를 반환하면 빈 문자열이 생성됩니다.

   2. sanitizerConfig를 policy의 관련 Realm과 policyValue에서 새니타이저 구성 가져오기의 결과로 둡니다.

   3. runScripts를 policyValue["runScripts"]로 두고, 기본값으로 false를 사용합니다.

   4. policy의 관련 Realm에서 새로운 TrustedHTMLParserOptions 인스턴스를 반환하며, 그 새니타이저 구성은 sanitizerConfig로 설정하고, runScripts는 runScripts로 설정합니다.

4. dataString을 policyValue를 문자열화한 결과로 둡니다.

5. policyValue가 null 또는 undefined이면 dataString을 빈 문자열로 설정합니다.

6. 타입 이름이 trustedTypeName인 인터페이스의 새 인스턴스를 반환하고, 연결된 데이터 값을 dataString으로 설정합니다.

3.3. 신뢰할 수 있는 타입 정책 값 가져오기

TrustedTypePolicy policy, 타입 이름 trustedTypeName, 문자열 또는 사전 value, 목록 arguments 및 불리언 throwIfMissing이 주어졌을 때 신뢰할 수 있는 타입 정책 값을 가져오려면 다음 단계를 수행합니다.

1. functionName을 주어진 trustedTypeName에 대한 함수 이름으로 두며, 다음 표를 기준으로 합니다.

   함수 이름	신뢰할 수 있는 타입 이름
   "createHTML"	"TrustedHTML"
   "createScript"	"TrustedScript"
   "createScriptURL"	"TrustedScriptURL"
   "createParserOptions"	"TrustedHTMLParserOptions"

2. function을 policy의 옵션[functionName]으로 둡니다.

3. function이 null이면:

   1. throwIfMissing이면 TypeError를 발생시킵니다.

   2. 그렇지 않으면 null을 반환합니다.

4. trustedTypeName이 "TrustedHTMLParserOptions"이면:

   1. value를 policy의 관련 Realm과 value이 주어졌을 때 파서 옵션 콜백 인수 생성 결과로 설정합니다.

5. args를 « value »로 둡니다.

6. arguments의 각 항목을 args에 추가합니다.

7. policyValue를 function을 args와 "rethrow"로 호출한 결과로 둡니다.

8. policyValue을 반환합니다.

3.4. 신뢰할 수 있는 타입 준수 입력 가져오기

참고: 다양한 인수 및 기본 정책 콜백 조합에서 이 알고리즘의 동작에 대한 요약은 § 2.4.3 입력 강제 적용 요약을 참조하십시오.

전역 객체 global, 문자열 또는 TrustedHTML input, TrustedHTMLParserOptions, ParseHTMLUnsafeOptions 또는 SetHTMLUnsafeOptions options, 문자열 sink, 선택적 "html" 또는 "xml" documentType(기본값 "html") 및 선택적 불리언 optionsFromAuthor (기본값 true)가 주어졌을 때 신뢰할 수 있는 타입 준수 입력을 가져오려면:

1. compliantOptions를 options로 둡니다.

2. documentType이 "html"이면:

   1. compliantOptions를 global, options, false, sink 및 optionsFromAuthor를 전달하여 신뢰할 수 있는 타입 준수 파서 옵션 가져오기를 호출한 결과로 설정합니다.

      참고: 작성자로부터 가져오는 대신 options을 직접 구성하는 싱크는 optionsFromAuthor에 false를 전달합니다. 예를 들어 createContextualFragment()는 runScripts를 true로 설정합니다.

   2. compliantOptions가 TrustedHTMLParserOptions의 인스턴스이면 (문자열화된 input, compliantOptions)를 반환합니다.

3. compliantHTML을 TrustedHTML, global, input, sink 및 "script"를 전달하여 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출한 결과로 둡니다.

4. 알고리즘에서 오류가 발생하면 오류를 다시 발생시킵니다.

5. (compliantHTML, compliantOptions)를 반환합니다.

3.5. 신뢰할 수 있는 타입 준수 문자열 가져오기

이 알고리즘은 인젝션 싱크와 함께 사용할 수 있는 문자열을 반환하며, 선택적으로 일치하는 신뢰할 수 있는 타입에서 래핑을 해제합니다. 또한 신뢰할 수 있는 타입 강제 적용 규칙이 준수되었음을 보장합니다.

TrustedType 타입(expectedType), 전역 객체(global), TrustedType 또는 문자열(input), 문자열(sink) 및 문자열(sinkGroup)이 주어졌을 때 신뢰할 수 있는 타입 준수 문자열을 가져오려면 다음 단계를 실행합니다.

1. input이 expectedType의 인스턴스이면 문자열화된 input을 반환하고 이 단계를 중단합니다.

2. requireTrustedTypes를 global, sinkGroup 및 true를 전달하여 싱크 타입에 신뢰할 수 있는 타입이 필요한가? 알고리즘을 실행한 결과로 둡니다.

3. requireTrustedTypes가 false이면 문자열화된 input을 반환하고 이 단계를 중단합니다.

4. convertedInput을 이 알고리즘과 동일한 인수로 기본 정책으로 값 처리를 실행한 결과로 둡니다.

5. 알고리즘에서 오류가 발생하면 오류를 다시 발생시키고 이후 단계를 중단합니다.

6. convertedInput이 null 또는 undefined이면 다음 단계를 실행합니다.

   1. disposition을 global, sink, sinkGroup 및 문자열화된 input을 source로 전달하여 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘을 실행한 결과로 둡니다.

   2. disposition이 “Allowed”이면 문자열화된 input을 반환하고 이후 단계를 중단합니다.

      참고: 이 단계는 기본 정책 거부가 보고되지만 보고 전용 모드에서는 무시되도록 보장합니다.

   3. TypeError를 발생시키고 이후 단계를 중단합니다.

7. 단언: convertedInput은 expectedType의 인스턴스입니다.

8. 문자열화된 convertedInput을 반환합니다.

3.6. 신뢰할 수 있는 타입 준수 파서 옵션 가져오기

참고: throwIfMissing은 신뢰할 수 있는 타입 준수 입력 가져오기에서 호출될 때 false입니다. 이 경우에도 검토가 필요한 작성자 제공 옵션에는 createParserOptions가 있는 기본 정책이 필요합니다. 동기식 HTML 조각 인젝션 싱크의 경우 결과 옵션의 TrustedHTMLParserOptions는 입력 문자열에 createHTML을 요구하지 않고도 신뢰할 수 있는 타입 강제 적용을 충족할 수 있습니다. 스트리밍 중이거나 HTML 문자열을 미리 검증할 수 없는 컨텍스트에서는 호출자가 throwIfMissing에 true를 전달하여 createParserOptions가 있는 기본 정책이 필요하도록 보장합니다. XML 문서에서는 파서 옵션으로 신뢰할 수 있는 타입 강제 적용을 충족할 수 없으며 XML 조각 싱크는 항상 신뢰할 수 있는 타입 준수 문자열 가져오기를 통한 준수 문자열 입력이 필요합니다.

전역 객체 global, TrustedHTMLParserOptions, SetHTMLUnsafeOptions 또는 ParseHTMLUnsafeOptions 중 하나인 input, 불리언 throwIfMissing, 문자열 sink 및 선택적 불리언 optionsFromAuthor(기본값 true)가 주어졌을 때 신뢰할 수 있는 타입 준수 파서 옵션을 가져오려면:

1. input이 TrustedHTMLParserOptions의 인스턴스이면 input을 반환합니다.

2. requireTrustedTypes를 global, "script" 및 true를 전달하여 싱크 타입에 신뢰할 수 있는 타입이 필요한가? 알고리즘을 실행한 결과로 둡니다.

3. requireTrustedTypes가 false이면 input을 반환합니다.

4. requirePolicy를 throwIfMissing으로 둡니다.

5. optionsFromAuthor가 true이고 input이 검토가 필요하면 requirePolicy를 true로 설정합니다.

   참고: TrustedHTML로 검토된 마크업도 검토되지 않은 새니타이저(예: replaceWithChildrenElements를 사용하는 새니타이저)로 파싱하거나 스크립트 실행이 활성화된 상태로 파싱하면 안전하지 않게 될 수 있습니다. 이러한 옵션은 TrustedHTMLParserOptions 또는 기본 정책의 createParserOptions에서 제공되어야 합니다.

6. defaultPolicy를 global의 신뢰할 수 있는 타입 정책 팩토리의 기본 정책 값으로 둡니다.

7. defaultPolicy가 null이면:

   1. requirePolicy가 true이면:

      1. disposition을 global, sink, "script" 및 빈 문자열을 source로 전달하여 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘을 실행한 결과로 둡니다.

      2. disposition이 “Allowed”이면 input을 반환합니다.

      3. TypeError를 발생시킵니다.

   2. input을 반환합니다.

8. function을 defaultPolicy의 옵션["createParserOptions"]으로 둡니다.

9. function이 null이면:

   1. requirePolicy가 true이면:

      1. disposition을 global, sink, "script" 및 빈 문자열을 source로 전달하여 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘을 실행한 결과로 둡니다.

      2. disposition이 “Allowed”이면 input을 반환합니다.

      3. TypeError를 발생시킵니다.

   2. input을 반환합니다.

10. argument를 global의 관련 Realm과 input이 주어졌을 때 파서 옵션 콜백 인수 생성 결과로 둡니다.

11. policyValue를 function을 « argument, "TrustedHTMLParserOptions", sink » 및 "rethrow"로 호출한 결과로 둡니다.

12. 알고리즘에서 오류가 발생하면 오류를 다시 발생시키고 이후 단계를 중단합니다.

13. policyValue가 null 또는 undefined이면:

    1. disposition을 global, sink, "script" 및 빈 문자열을 source로 전달하여 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘을 실행한 결과로 둡니다.

    2. disposition이 “Allowed”이면 input을 반환합니다.

       참고: 이 단계는 기본 정책 거부가 보고되지만 보고 전용 모드에서는 무시되도록 보장합니다.

    3. TypeError를 발생시킵니다.

14. runScripts를 policyValue["runScripts"]로 두고, 기본값으로 false를 사용합니다.

    참고: 기본 정책으로 호출될 때 createParserOptions 콜백은 최종 스크립트 실행 동작을 결정하여 호출자가 요청한 runScripts 옵션을 재정의합니다.

15. global의 관련 Realm에 새로운 TrustedHTMLParserOptions를 반환하며, 그 새니타이저 구성은 global의 관련 Realm과 policyValue에서 새니타이저 구성 가져오기의 결과로 설정하고, 그 runScripts는 runScripts로 설정합니다.

SetHTMLUnsafeOptions 또는 ParseHTMLUnsafeOptions options은 options["runScripts"]가 존재하고 true이거나, options["sanitizer"]가 존재하고 빈 SanitizerConfig가 아니면 검토가 필요합니다.

참고: 빈 SanitizerConfig는 파싱된 마크업을 변경하지 않습니다.

Realm realm과 사전 dictionary이 주어졌을 때 파서 옵션 콜백 인수를 생성하려면:

1. runScriptsInput을 dictionary["runScripts"]로 두고, 기본값으로 false를 사용합니다.

2. argument를 순서 있는 맵 «[ "runScripts" → runScriptsInput ]»으로 둡니다.

3. sanitizerInput을 realm과 dictionary에서 새니타이저 가져오기의 결과로 둡니다.

4. sanitizerInput이 null이 아니면 argument["sanitizer"]를 sanitizerInput으로 설정합니다.

5. argument를 반환합니다.

Realm realm과 사전 dictionary이 주어졌을 때 사전에서 새니타이저를 가져오려면:

1. sanitizerInput을 dictionary["sanitizer"]로 두고, 기본값을 null로 합니다.

2. sanitizerInput이 null이면 null을 반환합니다.

3. configuration을 null로 둡니다.

4. sanitizerInput이 SanitizerPresets이면:

   1. 단언: sanitizerInput은 "default"입니다.

   2. configuration을 내장 안전 기본 구성으로 설정합니다.

5. 그렇지 않고 sanitizerInput이 Sanitizer이면:

   1. configuration을 sanitizerInput의 구성으로 설정합니다.

6. 그렇지 않고 sanitizerInput이 SanitizerConfig이면:

   1. configuration을 sanitizerInput으로 설정합니다.

7. 단언: configuration은 null이 아닙니다.

8. sanitizer를 realm의 새로운 Sanitizer로 둡니다.

9. configuration과 true가 주어졌을 때 sanitizer를 구성합니다.

10. sanitizer를 반환합니다.

Realm realm과 사전 dictionary이 주어졌을 때 사전에서 새니타이저 구성 사본을 가져오려면:

1. sanitizer를 realm과 dictionary에서 새니타이저 가져오기의 결과로 둡니다.

2. sanitizer가 null이면 null을 반환합니다.

3. sanitizer의 구성을 반환합니다.

3.7. 기본 정책으로 값 처리

이 알고리즘은 존재하는 경우 인젝션 싱크에 할당될 값을 기본 정책을 통해 전달합니다.

TrustedType 타입(expectedType), 전역 객체(global), TrustedType 또는 문자열(input) 및 문자열(sink)이 주어졌을 때 기본 정책으로 값을 처리하려면 다음 단계를 실행합니다.

1. defaultPolicy를 global의 신뢰할 수 있는 타입 정책 팩토리의 기본 정책 값으로 둡니다.

2. policyValue를 신뢰할 수 있는 타입 정책 값 가져오기를 다음 인수로 실행한 결과로 둡니다.

   • defaultPolicy을 policy로 사용합니다.

   • 문자열화된 input을 value로 사용합니다.

   • expectedType의 타입 이름을 trustedTypeName으로 사용합니다.

   • « trustedTypeName, sink »를 arguments로 사용합니다.

   • false를 throwIfMissing으로 사용합니다.

3. 알고리즘에서 오류가 발생하면 오류를 다시 발생시키고 이후 단계를 중단합니다.

4. policyValue가 null 또는 undefined이면 policyValue을 반환합니다.

5. dataString을 policyValue를 문자열화한 결과로 둡니다.

6. 타입 이름이 trustedTypeName인 인터페이스의 새 인스턴스를 반환하고, 연결된 데이터 값을 dataString으로 설정합니다.

3.8. 스크립트 텍스트 준비

HTMLScriptElement 또는 SVGScriptElement (script)가 주어졌을 때 스크립트 텍스트를 준비하려면 다음 단계를 수행합니다.

1. script가 HTMLScriptElement이면 sink를 "HTMLScriptElement text"로 두고, 그렇지 않으면 "SVGScriptElement text"로 둡니다.

2. script의 스크립트 텍스트 값이 그 자식 텍스트 콘텐츠와 같지 않으면, script의 스크립트 텍스트를 다음 인수로 신뢰할 수 있는 타입 준수 문자열 가져오기를 실행한 결과로 설정합니다.

   • TrustedScriptURL을 expectedType으로 사용하고,

   • script의 Document의 관련 전역 객체를 global로 사용하고,

   • script의 자식 텍스트 콘텐츠 속성 값을 input으로 사용하고,

   • sink,

   • 'script'를 sinkGroup으로 사용합니다.

   알고리즘에서 오류가 발생하면 오류를 다시 발생시킵니다.

3.9. 신뢰할 수 있는 타입 준수 속성 값 가져오기

문자열 attributeName, 문자열 attributeNs, Element element 및 TrustedType 또는 문자열 newValue가 주어졌을 때 신뢰할 수 있는 타입 준수 속성 값을 가져오려면 다음 단계를 수행합니다.

1. attributeNs가 빈 문자열이면 attributeNs를 null로 설정합니다.

2. attributeData를 다음 인수로 속성에 대한 신뢰할 수 있는 타입 데이터 가져오기 알고리즘을 실행한 결과로 설정합니다.

   • element

   • attributeName

   • attributeNs

3. attributeData가 null이면:

   1. newValue가 문자열이면 newValue을 반환합니다.

   2. 단언: newValue은 TrustedHTML 또는 TrustedScript 또는 TrustedScriptURL입니다.

   3. value의 연결된 데이터를 반환합니다.

4. expectedType을 attributeData의 네 번째 멤버 값으로 둡니다.

5. sink를 attributeData의 다섯 번째 멤버 값으로 둡니다.

6. 다음 인수로 신뢰할 수 있는 타입 준수 문자열 가져오기를 실행한 결과를 반환합니다.

   • expectedType

   • newValue을 input으로 사용합니다.

   • element의 노드 문서의 관련 전역 객체를 global로 사용합니다.

   • sink

   • 'script'를 sinkGroup으로 사용합니다.

알고리즘에서 오류가 발생하면 오류를 다시 발생시킵니다.

3.10. 속성에 대한 신뢰할 수 있는 타입 데이터 가져오기

element, attribute, attributeNs가 주어졌을 때 속성에 대한 신뢰할 수 있는 타입 데이터를 가져오려면 다음 단계를 수행합니다.

아래에서 사용되는 이벤트 핸들러 콘텐츠 속성 개념은 모호합니다. 이 명세에는 이벤트 핸들러 속성을 식별하기 위한 더 나은 메커니즘이 필요합니다. https://github.com/w3c/trusted-types/issues/520을 참조하십시오.

1. data를 null로 둡니다.

2. attributeNs가 null이고, « HTML 네임스페이스, SVG 네임스페이스, MathML 네임스페이스 »가 element의 네임스페이스를 포함하며, attribute가 이벤트 핸들러 콘텐츠 속성의 이름이면:

   1. (Element, null, attribute, TrustedScript, "Element " + attribute)를 반환합니다.

3. 다음 표에서 element이 첫 번째 열에 있고, attributeNs가 두 번째 열에 있으며, attribute가 세 번째 열에 있는 행을 찾습니다. 일치하는 행이 발견되면 data를 그 행으로 설정합니다.

   요소	속성 네임스페이스	속성 로컬 이름	TrustedType	싱크
   HTMLIFrameElement	null	"srcdoc"	TrustedHTML	"HTMLIFrameElement srcdoc"
   HTMLScriptElement	null	"src"	TrustedScriptURL	"HTMLScriptElement src"
   SVGScriptElement	null	"href"	TrustedScriptURL	"SVGScriptElement href"
   SVGScriptElement	XLink 네임스페이스	"href"	TrustedScriptURL	"SVGScriptElement href"

4. data를 반환합니다.

4. 통합

typedef (TrustedHTML or TrustedScript or TrustedScriptURL) TrustedType;

4.1. HTML과의 통합

Window 및 Worker 객체에는 신뢰할 수 있는 타입 정책 팩토리가 있으며, 이는 TrustedTypePolicyFactory 객체입니다.

4.1.1. WindowOrWorkerGlobalScope 인터페이스 확장

이 문서는 HTML에서 정의한 WindowOrWorkerGlobalScope 인터페이스를 확장합니다.

partial interface mixin WindowOrWorkerGlobalScope {
  readonly attribute TrustedTypePolicyFactory trustedTypes;
};

trustedTypes getter 단계는 this의 관련 전역 객체의 신뢰할 수 있는 타입 정책 팩토리를 반환하는 것입니다.

4.1.2. 스크립트 강제 적용

이 문서는 애플리케이션이 동적으로 생성된 스크립트를 제어할 수 있도록 HTMLScriptElement 자식 텍스트 콘텐츠를 설정하는 방식을 수정합니다. 이를 위해 innerText 및 textContent 속성을 HTMLScriptElement에 직접 추가합니다. 이러한 속성의 동작은 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출하는 추가 동작을 제외하면 원래 대응 항목과 동일합니다.

참고: 이러한 IDL 속성을 사용하는 것이 스크립트의 URL 또는 텍스트를 동적으로 설정하는 권장 방법입니다. 속성 노드나 텍스트 노드를 직접 조작하면 스크립트를 준비할 때 최종 값에 기본 정책이 호출됩니다.

partial interface HTMLScriptElement {
 [CEReactions] attribute (TrustedScript or [LegacyNullToEmptyString] DOMString) innerText;
 [CEReactions] attribute (TrustedScript or DOMString)? textContent;
 [CEReactions] attribute (TrustedScriptURL or USVString) src;
 [CEReactions] attribute (TrustedScript or DOMString) text;
};

4.1.2.1. 신뢰할 수 있는 값을 가진 슬롯

HTMLScriptElement 및 SVGScriptElement에는 다음이 있습니다.

연결된 문자열 스크립트 텍스트.

준수 싱크를 통해 설정된, 실행할 스크립트의 본문을 포함하는 문자열입니다. 스크립트의 자식 텍스트 콘텐츠와 같습니다. 초기값은 빈 문자열입니다.

4.1.2.2. innerText IDL 속성

innerText setter 단계는 다음과 같습니다.

1. value를 TrustedScript, this의 관련 전역 객체, 주어진 값, HTMLScriptElement innerText 및 script로 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출한 결과로 둡니다.

2. this의 스크립트 텍스트 값을 value로 설정합니다.

3. this와 value로 내부 텍스트 설정 단계를 실행합니다.

innerText getter 단계는 다음과 같습니다.

1. this로 텍스트 가져오기 단계를 실행한 결과를 반환합니다.

4.1.2.3. textContent IDL 속성

textContent setter 단계에서는 주어진 값이 null이면 대신 빈 문자열인 것처럼 처리한 다음 아래 설명대로 수행합니다.

1. value를 TrustedScript, this의 관련 전역 객체, 주어진 값, HTMLScriptElement textContent 및 script로 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출한 결과로 둡니다.

2. this의 스크립트 텍스트 값을 value로 설정합니다.

3. this와 value로 텍스트 콘텐츠 설정을 실행합니다.

textContent getter 단계는 다음과 같습니다.

1. this로 텍스트 콘텐츠 가져오기를 실행한 결과를 반환합니다.

참고: 현재는 SVGScriptElement에 해당하는 항목을 추가하지 않습니다. https://github.com/w3c/trusted-types/issues/512을 참조하십시오.

4.1.2.4. text IDL 속성

text setter 단계 알고리즘을 다음과 같이 업데이트합니다.

1. value를 TrustedScript, this의 관련 전역 객체, 주어진 값, HTMLScriptElement text 및 script로 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출한 결과로 둡니다.
2. this의 스크립트 텍스트 값을 주어진 값으로 설정합니다.

3. 주어진 값으로 this 내부에서 문자열 모두 바꾸기를 수행합니다.

4.1.2.5. src IDL 속성

src getter 단계는 다음과 같습니다.

1. element를 this의 요소 가져오기를 실행한 결과로 둡니다.
2. contentAttributeValue를 this의 콘텐츠 속성 가져오기를 실행한 결과로 둡니다.
3. contentAttributeValue가 null이면 빈 문자열을 반환합니다.
4. urlString을 element의 노드 문서에 상대적인 contentAttributeValue이 주어졌을 때 URL을 인코딩-파싱-직렬화한 결과로 둡니다.
5. urlString이 실패가 아니면 urlString을 반환합니다.
6. contentAttributeValue을 스칼라 값 문자열로 변환하여 반환합니다.

src setter 단계는 다음과 같습니다.

1. value를 TrustedScriptURL, this의 관련 전역 객체, 주어진 값, HTMLScriptElement src 및 script로 신뢰할 수 있는 타입 준수 문자열 가져오기를 호출한 결과로 둡니다.
2. this의 src 콘텐츠 속성을 value로 설정합니다.

4.1.2.6. 파서에서 슬롯 값 설정

이 문서는 스크립트가 생성될 때 스크립트 텍스트 값을 설정하도록 HTML 파서를 수정합니다.

텍스트 삽입 모드 알고리즘을 다음과 같이 수정합니다.

태그 이름이 "script"인 종료 태그

...

script의 스크립트 텍스트 값을 그 자식 텍스트 콘텐츠로 설정합니다.

활성 추측적 HTML 파서가 null이면 script 스크립트 요소를 준비합니다. 이로 인해 일부 스크립트가 실행될 수 있고, 그 결과 새 문자가 토크나이저에 삽입될 수 있으며, 토크나이저가 더 많은 토큰을 출력하여 파서의 재진입 호출이 발생할 수 있습니다.

...

위 알고리즘은 파싱 도중 스크립트 요소의 콘텐츠가 변경되는 경우를 고려하지 않습니다. 구현자는 이 경우로부터 보호되도록 해야 합니다. https://github.com/w3c/trusted-types/issues/507을 참조하십시오.

SVG 스크립트 요소 처리에 대한 적절한 정의가 없습니다. 그러나 구현은 SVGScriptElement 처리에도 유사한 변경을 적용해야 합니다.

4.1.2.7. 슬롯 값 검증

스크립트 요소 준비 알고리즘의 처음 몇 단계를 다음과 같이 수정합니다.

1. el의 이미 시작됨이 true이면 반환합니다.

2. parser document를 el의 파서 문서로 둡니다.

3. el의 파서 문서를 null로 설정합니다.

   이는 파서에 삽입된 script 요소가 실행에 실패하여 파서가 이를 실행하려 할 때, 예를 들어 비어 있거나 지원되지 않는 스크립팅 언어를 지정하여 실패하더라도, 나중에 다른 스크립트가 이를 변경하여 다시 실행할 수 있게 하기 위한 것입니다.

4. parser document가 null이 아니고 el에 async 속성이 없으면 el의 강제 비동기를 true로 설정합니다.

   이는 파서에 삽입된 script 요소가 파서가 실행하려 할 때 실패하지만 나중에 스크립트가 동적으로 업데이트한 후 실행되는 경우 async 속성이 설정되지 않았더라도 비동기 방식으로 실행되도록 하기 위한 것입니다.

5. el에 대해 스크립트 텍스트 준비 알고리즘을 실행합니다. 해당 알고리즘에서 오류가 발생하면 반환합니다.

6. source text를 el의 자식 텍스트 콘텐츠로 둡니다. 스크립트 텍스트 값으로 둡니다.

7. ...

SVG 스크립트 요소 처리에 대한 적절한 정의가 없습니다. 그러나 구현은 SVGScriptElement 처리에도 유사한 변경을 적용해야 합니다.

4.2. 콘텐츠 보안 정책과의 통합

4.2.1. require-trusted-types-for 지시문

이 문서는 새로운 콘텐츠 보안 정책 지시문인 require-trusted-types-for을 정의합니다.

require-trusted-types-for 지시문은 현재 Realm의 특정 그룹에 속하는 모든 인젝션 싱크에 대해 신뢰할 수 있는 타입 프레임워크를 구성합니다. 구체적으로, 주어진 그룹의 인젝션 싱크에 문자열 값이 전달될 때 어떤 동작을 해야 하는지 정의합니다(즉, 그러한 싱크에 타입 기반 강제 적용을 활성화해야 하는지).

참고: 현재는 § 2.1.1 DOM XSS 인젝션 싱크에 대한 강제 적용만 명시되어 있습니다.

지시문의 이름 및 값의 구문은 다음 ABNF로 설명됩니다.

directive-name = "require-trusted-types-for"
directive-value = trusted-types-sink-group-keyword *( required-ascii-whitespace trusted-types-sink-group-keyword)
trusted-types-sink-group-keyword = "'" trusted-types-sink-group "'"
trusted-types-sink-group = "script"

Content-Security-Policy: require-trusted-types-for 'script'

4.2.1.1. require-trusted-types-for 사전 내비게이션 검사

요청(request), 문자열 navigation type 및 정책(policy)이 주어졌을 때, 이 알고리즘은 내비게이션이 require-trusted-types-for 지시문의 제약을 위반하면 "Blocked"를 반환하고 그렇지 않으면 "Allowed"를 반환합니다. 이는 require-trusted-types-for 지시문의 사전 내비게이션 검사를 구성합니다.

참고: 이 알고리즘은 javascript: URL로 내비게이션할 때 실행될 코드가 다른 CSP 지시문이 부과하는 모든 제한에 더해 기본 정책의 createScript 함수를 통과해야 하도록 보장합니다.

1. request의 url의 스킴이 "javascript"가 아니면 "Allowed"를 반환하고 이후 단계를 중단합니다.

2. urlString을 request의 url에 URL 직렬화기를 실행한 결과로 둡니다.

3. encodedScriptSource를 urlString의 선두 "javascript:"를 제거한 결과로 둡니다.

4. convertedScriptSource를 다음 인수로 기본 정책으로 값 처리 알고리즘을 실행한 결과로 둡니다.

   • TrustedScript를 expectedType으로 사용합니다.

   • request의 클라이언트의 전역 객체를 global로 사용합니다.

   • encodedScriptSource를 input으로 사용합니다.

   • "Location href"를 sink로 사용합니다.

   해당 알고리즘에서 오류가 발생했거나 convertedScriptSource가 TrustedScript 객체가 아니면 "Blocked"를 반환하고 이후 단계를 중단합니다.

5. urlString을 문자열화된 convertedScriptSource 앞에 "javascript:"을 추가한 결과로 설정합니다.

6. newURL을 urlString에 URL 파서를 실행한 결과로 둡니다. 파서가 실패를 반환하면 "Blocked"를 반환하고 이후 단계를 중단합니다.

7. request의 url을 newURL로 설정합니다.

   참고: 사전 내비게이션 검사에서는 다른 CSP 지시문이 javascript: URL에 작동하지 않습니다. javascript: URL을 검사하는 다른 지시문은 나중에 인라인 검사에서 수정된 URL에 작동합니다.

8. "Allowed"를 반환합니다.

4.2.2. trusted-types 지시문

이 문서는 새로운 콘텐츠 보안 정책 지시문인 trusted-types를 정의합니다. trusted-types 지시문은 신뢰할 수 있는 타입 정책의 생성을 제어합니다.

지시문의 이름 및 값의 구문은 다음 ABNF로 설명됩니다.

directive-name = "trusted-types"
directive-value = serialized-tt-configuration
serialized-tt-configuration = ( tt-expression *( required-ascii-whitespace tt-expression ) )
tt-expression = tt-policy-name  / tt-keyword / tt-wildcard
tt-wildcard = "*"
tt-policy-name = 1*( ALPHA / DIGIT / "-" / "#" / "=" / "_" / "/" / "@" / "." / "%")
tt-keyword = "'allow-duplicates'" / "'none'"

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types one two

Content-Security-Policy: trusted-types; require-trusted-types-for 'script'

키워드 'none'을 사용하여 위 내용을 명시적으로 표현할 수 있습니다.

Content-Security-Policy: trusted-types 'none'; require-trusted-types-for 'script'

키워드 'allow-duplicates'는 이미 사용된 이름으로 정책을 생성할 수 있게 합니다.

Content-Security-Policy: trusted-types foo bar 'allow-duplicates'

default라는 이름의 정책이 목록에 있으면 기본 정책을 나타냅니다. 인젝션 싱크에 전달되는 모든 문자열은 바로 거부되는 대신 이를 거쳐 전달됩니다.

Content-Security-Policy: trusted-types one two default

4.2.3. 싱크 타입에 신뢰할 수 있는 타입이 필요한가?

이 알고리즘은 인젝션 싱크가 신뢰할 수 있는 타입을 요구하면 true를 반환하고, 그렇지 않으면 false를 반환합니다.

전역 객체(global), 문자열 (sinkGroup) 및 불리언(includeReportOnlyPolicies)이 주어졌을 때 싱크 타입에 신뢰할 수 있는 타입이 필요한가? 알고리즘은 다음 단계를 수행합니다.

1. global의 CSP 목록에 있는 각 policy에 대해:

   1. policy의 지시문 집합에 지시문 중 그 이름이 "require-trusted-types-for"인 것이 없으면 다음 policy로 건너뜁니다.

   2. directive를 이름이 "require-trusted-types-for"인 policy의 directive set의 지시문으로 둡니다.

   3. directive의 값에 sinkGroup과 일치하는 trusted-types-sink-group이 포함되어 있지 않으면 다음 policy로 건너뜁니다.

   4. policy의 처리 방식이 "enforce"이면 enforced를 true로 두고, 그렇지 않으면 false로 둡니다.

   5. enforced가 true이면 true를 반환합니다.

   6. includeReportOnlyPolicies가 true이면 true를 반환합니다.

2. false를 반환합니다.

4.2.4. 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가?

이 알고리즘은 인젝션 싱크가 신뢰할 수 있는 타입을 요구하면 "Blocked"를 반환하고, 그렇지 않으면 "Allowed"를 반환합니다.

전역 객체(global), 문자열(sink), 문자열(sinkGroup) 및 문자열(source)이 주어졌을 때 싱크 타입 불일치 위반을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘은 다음 단계를 수행합니다.

1. result를 "Allowed"로 둡니다.

2. sample을 source로 둡니다.

3. sink가 "Function"이면:

   1. sample이 "function anonymous"로 시작하면 이를 sample에서 제거합니다.

   2. 그렇지 않고 sample이 "async function anonymous"로 시작하면 이를 sample에서 제거합니다.

   3. 그렇지 않고 sample이 "function* anonymous"로 시작하면 이를 sample에서 제거합니다.

   4. 그렇지 않고 sample이 "async function* anonymous"로 시작하면 이를 sample에서 제거합니다.

4. global의 CSP 목록에 있는 각 policy에 대해:

   1. policy의 지시문 집합에 지시문 중 그 이름이 "require-trusted-types-for"인 것이 없으면 다음 policy로 건너뜁니다.

   2. directive를 이름이 "require-trusted-types-for"인 policy의 directive set의 지시문으로 둡니다.

   3. directive의 값에 sinkGroup과 일치하는 trusted-types-sink-group이 포함되어 있지 않으면 다음 policy로 건너뜁니다.

   4. violation을 global, policy 및 "require-trusted-types-for"에 대해 전역 객체, 정책 및 지시문에 대한 위반 객체 생성을 실행한 결과로 둡니다.

   5. violation의 리소스를 "trusted-types-sink"로 설정합니다.

   6. trimmedSample을 sample의 처음 40 문자를 포함하는 부분 문자열로 둡니다.

   7. violation의 샘플을 목록 « sink, trimmedSample «을 "|"을 구분자로 사용하여 연결한 결과로 설정합니다.

   8. violation에 대해 위반 보고를 실행합니다.

   9. policy의 처리 방식이 "enforce"이면 result를 "Blocked"로 설정합니다.

5. result를 반환합니다.

4.2.5. 신뢰할 수 있는 타입 정책 생성을 콘텐츠 보안 정책으로 차단해야 하는가?

이 알고리즘은 TrustedTypePolicy가 생성되어서는 안 되면 "Blocked"를 반환하고, 그렇지 않으면 "Allowed"를 반환합니다.

전역 객체(global), 문자열 (policyName) 및 문자열 목록 (createdPolicyNames)이 주어졌을 때 신뢰할 수 있는 타입 정책 생성을 콘텐츠 보안 정책으로 차단해야 하는가? 알고리즘은 다음 단계를 수행합니다.

1. result를 "Allowed"로 둡니다.

2. global의 CSP 목록에 있는 각 policy에 대해:

   1. createViolation을 false로 둡니다.

   2. policy의 지시문 집합에 이름이 "trusted-types"인 지시문이 포함되어 있지 않으면 다음 policy로 건너뜁니다.

   3. directive를 이름이 "trusted-types"인 policy의 directive set의 지시문으로 둡니다.

   4. directive의 값에 'none' 값과 일치하는 tt-keyword만 포함되어 있으면 createViolation을 true로 설정합니다.

      참고: 다른 CSP 지시문과 마찬가지로 다른 키워드 또는 정책 이름이 있으면 'none' 키워드는 무시됩니다.

   5. createdPolicyNames에 policyName이 포함되어 있고 directive의 값에 'allow-duplicates' 값과 일치하는 tt-keyword가 포함되어 있지 않으면 createViolation을 true로 설정합니다.

      참고: trusted-types policyA policyB 'allow-duplicates'는 작성자가 중복된 이름의 정책을 생성할 수 있게 합니다.

   6. directive의 값에 값이 policyName인 tt-policy-name이 포함되어 있지 않고, directive의 값에도 tt-wildcard가 포함되어 있지 않으면 createViolation을 true로 설정합니다.

      참고: trusted-types *는 작성자가 고유한 어떤 이름으로든 정책을 생성할 수 있게 합니다. 같은 이름의 여러 정책을 허용하려면 trusted-types * 'allow-duplicates'를 사용하거나 trusted-types 지시문을 전혀 설정하지 마십시오.

   7. createViolation이 false이면 다음 policy로 건너뜁니다.

   8. violation을 global, policy 및 "trusted-types"에 대해 전역 객체, 정책 및 지시문에 대한 위반 객체 생성을 실행한 결과로 둡니다.

   9. violation의 리소스를 "trusted-types-policy"로 설정합니다.

   10. violation의 샘플을 policyName의 처음 40자를 포함하는 부분 문자열로 설정합니다.

   11. violation에 대해 위반 보고를 실행합니다.

   12. policy의 처리 방식이 "enforce"이면 result를 "Blocked"로 설정합니다.

3. result를 반환합니다.

5. 보안 고려 사항

신뢰할 수 있는 타입은 적극적으로 악의적인 실행 환경에서 인젝션 싱크에 대한 접근을 보호하기 위한 것이 아닙니다. 애플리케이션은 악의적이지 않은 작성자가 작성한다고 가정하며, 그 목적은 보안 버그를 초래할 수 있는 개발자의 실수를 방지하는 것이지 정책 제한을 적극적으로 우회하려는 자사 악성 코드로부터 방어하는 것이 아닙니다. 아래에서는 신뢰할 수 있는 타입이 강제 적용되는 환경에서도 여전히 위험한 것으로 이미 식별된 벡터를 열거합니다.

5.1. 문서 간 벡터

신뢰할 수 있는 타입이 강제 적용되는 창에서 실행되는 코드는 정책 제한을 우회하는 노드를 동적으로 생성할 수 없지만, 동일한 제한 집합이 없는 다른 창의 문서에서 그러한 노드를 가져오거나 채택할 수 있습니다. 본질적으로 악의적인 작성자가 제한된 문서와 제한되지 않은 문서가 공모하도록 구성하면 신뢰할 수 있는 타입을 우회할 수 있습니다. 극단적인 경우 제한된 문서는 문자열에서 Blob을 생성하고 그것으로 내비게이션할 수 있습니다.

CSP 전파 규칙(콘텐츠 보안 정책 3 § 7.8 우회를 방지하기 위한 CSP 상속 참조)은 이 문제를 부분적으로 해결합니다. 새 로컬 스킴 문서가 동일한 제한 집합을 상속하므로, 예를 들어 script-src 제한을 사용하여 Blob 콘텐츠에 대한 인젝션이 스크립트를 실행하지 못하도록 할 수 있습니다. 이 문제를 포괄적으로 해결하려면 Origin Policy와 같은 다른 메커니즘을 사용하여 전체 출처에 기준 보안 규칙이 적용되도록 해야 합니다.

5.2. 사용 중단된 기능

오랫동안 사용 중단되었고 거의 사용되지 않는 일부 플랫폼 기능에는 신뢰할 수 있는 타입이 적용되지 않으며, 악의적인 작성자가 제한을 극복하는 데 사용할 가능성이 있습니다.

• HTML 가져오기

5.3. 스크립트 가젯

문자열에서 DOM 트리를 생성하는 결과를 낳는 많은 작업에서 신뢰할 수 있는 타입 로직이 호출되지만, 이를 문서 내의 모든 DOM 트리 생성을 보호하는 메커니즘으로 취급해서는 안 됩니다. 이는 특히 스크립트 가젯이 존재하는 경우 중요합니다. 이 경우 애플리케이션은 일반적으로 무해한 DOM 요소나 속성의 콘텐츠에 반응합니다. DOM API를 직접 사용하는 개발자는 신뢰할 수 있는 타입을 사용하지 않고도 그러한 가젯을 트리거할 수 있습니다. 그러나 가젯이 DOM XSS를 트리거하려면 정책을 통해 신뢰할 수 있는 타입 값을 얻어야 합니다. 정책 규칙 자체가 제약을 강제하거나 데이터를 검증하지 않는다면 작성자는 신뢰할 수 있는 타입 정책에 전달되는 데이터가 실제로 신뢰할 수 있는지 확인해야 합니다.

5.4. 정책 설계 모범 사례

신뢰할 수 있는 타입은 인젝션 싱크를 통해 취약점을 도입할 수 있는 코드 범위를 정책의 구현으로 제한합니다. 이 설계에서도 안전하지 않은 정책은 여전히 인젝션 싱크를 신뢰할 수 없는 데이터에 노출할 수 있습니다. 가능한 모든 입력에 대해 안전한 정책을 사용하거나 안전하지 않은 정책에 대한 접근을 제한하여 공격자가 제어하지 않는 입력으로만 호출되도록 하는 데 특별히 주의를 기울여야 합니다.

정책은 사용자 정의 JavaScript 코드이므로 전역 상태에 크게 의존하도록 작성될 수 있습니다. 이는 권장하지 않습니다. 정책은 가능한 한 자체적으로 완결되어야 합니다. 정책이 내리는 보안 결정에 영향을 줄 수 있는 모든 객체는 사실상 정책의 일부가 되며, 함께 보호하고 검토해야 합니다.

안전하지 않은 마크업(예: 스크립트 또는 이벤트 핸들러)을 제거하지 않는 구성을 반환하는 createParserOptions 콜백은 DOM XSS에 대한 보호를 제공하지 않습니다. 정책 작성자는 또한 createParserOptions에 전달되는 argument["sanitizer"]의 호출자 제공 새니타이저를 신중하게 검사해야 합니다. 호출자의 새니타이저를 맹목적으로 신뢰하거나 그대로 전달하면 검토되지 않은 구성이 파싱을 지배하게 됩니다. createParserOptions는 입력 마크업이 기존 TrustedHTML 인스턴스인 경우에도 실행되므로, 기본 정책은 검토되지 않은 호출자 옵션이 애플리케이션 전체의 새니타이징 또는 스크립트 실행 제약을 우회할 수 없도록 합니다. 이러한 콜백이 없으면 TrustedHTML을 호출자가 제공한 비어 있지 않은 새니타이저 또는 true로 설정된 runScripts와 결합할 수 없습니다. 이는 검토된 마크업을 안전하지 않게 만들 수 있기 때문입니다.

안전한 정책 설계에 관한 외부 문서를 참조하십시오.

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

이 명세는 애플리케이션 내에서 실행되는 스크립트의 동작을 부분적으로 관찰하고 변경할 수 있습니다. 예를 들어 인젝션 싱크에 대한 특정 작업을 실패하게 하거나 기본 정책으로 그 효과를 모니터링하고 변경할 수 있습니다. 그러나 먼저 실행되는 스크립트는 적절한 속성 설명자를 재정의함으로써 이미 이러한 기능을 갖습니다.

애플리케이션은 신뢰할 수 있는 타입 제한 위반을 보고할 수 있습니다. 위반 보고서에는 인젝션 싱크에 전달된 축약된 페이로드(싱크 이름을 포함해 40자)가 포함됩니다. 이 기능은 콘텐츠 보안 정책의 보고 메커니즘을 재사용합니다.

7. 구현 고려 사항

7.1. 벤더별 확장 기능 및 애드온

신뢰할 수 있는 타입이 부과하는 제한은 애드온, 확장 기능 또는 북마클릿과 같은 사용자 에이전트 기능의 작동을 방해해서는 안 됩니다. 이러한 종류의 기능은 일반적으로 [html-design-principles]에서 제시하는 것처럼 페이지 작성자보다 사용자의 우선권을 높입니다. 특히 확장 기능은 인젝션 싱크에 기본 정책 실행, 위반 생성 또는 값 거부를 트리거하지 않고 문자열을 전달할 수 있어야 합니다.