보안 컨텍스트

1. 소개

이 섹션은 규범적이지 않습니다.

웹 플랫폼이 더 유용하고 강력한 애플리케이션을 가능하게 하도록 확장됨에 따라, 이러한 애플리케이션을 가능하게 하는 기능이 최소한의 보안 수준을 충족하는 컨텍스트에서만 활성화되도록 보장하는 것이 점점 더 중요해지고 있습니다. [SECURING-WEB]의 TAG 권고의 연장선으로, 이 문서는 웹에서 기능 오남용에 대한 위협 모델(§ 4.1 위협 모델 참조)을 설명하고, 새로운 기능을 명세하는 문서에 포함되어야 하는 규범적 요구사항(§ 7 구현 고려사항 참조)을 개략적으로 설명합니다.

여기서 논의되는 가장 명확한 요구사항은 민감하거나 개인적인 데이터에 접근할 수 있는 애플리케이션 코드가 데이터 무결성을 보장하는 인증된 채널을 통해 기밀적으로 전달되어야 한다는 점입니다. 코드를 안전하게 전달한다고 해서 애플리케이션이 항상 사용자의 보안 및 개인정보 요구를 충족한다는 보장은 없지만, 이는 필수 전제 조건입니다.

덜 명확하게는, 인증되고 기밀성이 보장된 채널을 통해 전달된 애플리케이션 코드만으로는 비보안 컨텍스트에서 강력한 기능 사용을 제한하기에 충분하지 않습니다. § 4.2 조상 위험에서 설명하듯이, 협력 프레임은 기능에 대한 견고한 제한을 우회하는 데 악용될 수 있습니다. 아래에 정의된 알고리즘은 이러한 우회를 어렵고 사용자에게 명확하게 만듭니다.

다음 예시는 이어지는 규범적 텍스트를 요약합니다:

1.1. 최상위 문서

http://example.com/이 최상위 브라우징 컨텍스트에서 열렸을 때, 인증 및 암호화된 채널을 통해 전달되지 않았으므로 보안 컨텍스트가 아닙니다.

https://example.com/이 최상위 브라우징 컨텍스트에서 열렸을 때, 인증 및 암호화된 채널을 통해 전달되었으므로 보안 컨텍스트입니다.

보안 컨텍스트가 https://example.com/을 새 창에서 열 경우, 해당 새 창도 자체적으로 안전하므로 보안 컨텍스트가 됩니다:

마찬가지로, 비보안 컨텍스트가 https://example.com/을 새 창에서 열 경우, 해당 새 창은 보안 컨텍스트가 되며, 오프너가 비보안이더라도 보안이 유지됩니다:

1.2. 프레임된 문서

프레임된 문서는 보안 컨텍스트가 될 수 있으며, 신뢰할 수 있는 원본에서 전달되고 또한 보안 컨텍스트에 포함되어야 합니다. 즉:

https://example.com/이 최상위 브라우징 컨텍스트에서 https://sub.example.com/을 프레임으로 열면, 둘 다 인증 및 암호화된 채널을 통해 전달되었으므로 보안 컨텍스트입니다.

https://example.com/이 http://non-secure.example.com/을 프레임으로 열 수 있다면(예: 사용자가 혼합 콘텐츠 검사를 비활성화한 경우), 최상위 프레임은 보안이 유지되지만 프레임된 콘텐츠는 보안 컨텍스트가 아닙니다.

반면, https://example.com/이 http://non-secure.example.com/에 프레임되어 있으면, 조상이 인증 및 암호화된 채널을 통해 전달되지 않았으므로 보안 컨텍스트가 아닙니다.

1.3. 웹 워커

전용 워커는 프레임된 문서와 유사합니다. 보안 컨텍스트가 되려면 신뢰할 수 있는 원본에서 전달되어야 하며, 소유자 역시 보안 컨텍스트여야 합니다:

https://example.com/이 최상위 브라우징 컨텍스트에서 https://example.com/worker.js를 실행하면, 문서와 워커 모두 보안 컨텍스트입니다.

http://non-secure.example.com/이 최상위 브라우징 컨텍스트에서 https://example.com/을 프레임으로 열고, https://example.com/worker.js를 실행하면, 프레임된 문서와 워커 모두 보안 컨텍스트가 아닙니다.

1.4. 공유 워커

여러 컨텍스트가 공유 워커에 연결할 수 있습니다. 보안 컨텍스트가 공유 워커를 생성하면, 해당 워커는 보안 컨텍스트가 되며, 다른 보안 컨텍스트만 연결할 수 있습니다. 비보안 컨텍스트가 공유 워커를 생성하면, 해당 워커는 보안 컨텍스트가 아니며 다른 비보안 컨텍스트만 연결할 수 있습니다.

https://example.com/이 최상위 브라우징 컨텍스트에서 https://example.com/worker.js를 공유 워커로 실행하면, 문서와 워커 모두 보안 컨텍스트로 간주됩니다.

다른 최상위 브라우징 컨텍스트(예: 새 창)에서 https://example.com/은 보안 컨텍스트이므로 보안 공유 워커에 접근할 수 있습니다:

https://example.com/이 http://non-secure.example.com/에 중첩되어 있으면, 보안 컨텍스트가 아니므로 보안 워커에 연결할 수 없습니다.

마찬가지로, https://example.com/이 http://non-secure.example.com/에 중첩되어 있고 https://example.com/worker.js를 공유 워커로 실행하면, 문서와 워커 모두 비보안으로 간주됩니다.

1.5. 서비스 워커

서비스 워커는 항상 보안 컨텍스트입니다. 보안 컨텍스트에서만 등록할 수 있으며, 클라이언트도 보안 컨텍스트여야 합니다.

https://example.com/이 최상위 브라우징 컨텍스트에서 https://example.com/service.js를 등록하면, 문서와 서비스 워커 모두 보안 컨텍스트로 간주됩니다.

2. 프레임워크

이 섹션은 규범적이지 않습니다.

2.1. WebIDL과의 통합

연산자에 대해 새로운 [SecureContext] 특성이 제공되며, 이는 해당 연산자가 보안 컨텍스트에서만 노출되도록 보장합니다. 다음 예시를 참고하세요:

interface ExampleFeature {
  // 이 호출은 모든 컨텍스트에서 성공합니다.
  Promise <double> calculateNotSoSecretResult();

  // 이 연산은 비보안 컨텍스트에서는 노출되지 않습니다.
  [SecureContext] Promise<double> calculateSecretResult();

  // 아래와 같이, 이 연산 역시 비보안 컨텍스트에서는 노출되지 않습니다.
  [SecureContext] boolean getSecretBoolean();
};

[SecureContext]
interface SecureFeature {
  // 이 인터페이스는 비보안 컨텍스트에 노출되지 않습니다.
  Promise<any> doAmazingThing();
};

규격 작성자는 새로운 기능을 정의할 때 이 특성 사용을 권장합니다.

2.2. HTML과의 통합

2.2.1. 공유 워커

SharedWorker 생성자는 보안 컨텍스트가 보안 컨텍스트가 아닌 워커에 연결을 시도하거나, 비보안 컨텍스트가 보안 컨텍스트 워커에 연결을 시도하면 "SecurityError" DOMException 예외를 발생시킵니다.

2.2.2. 기능 감지

애플리케이션은 isSecureContext 부울 값을 WindowOrWorkerGlobalScope 에서 확인하여 보안 컨텍스트에서 실행 중인지 판별할 수 있습니다.

2.2.3. 보안 및 비보안 컨텍스트

HTML 현행 표준은 환경이 보안 컨텍스트인지 비보안 컨텍스트인지 정의합니다. 이는 다른 규격에서 사용하는 주요 메커니즘입니다.

글로벌 오브젝트가 주어졌을 때, 규격에서는 해당 관련 설정 오브젝트(환경)가 보안 컨텍스트인지 확인할 수 있습니다.

3. 알고리즘

3.1. `origin`이 잠재적으로 신뢰할 수 있는가?

잠재적으로 신뢰할 수 있는 origin이란 사용자 에이전트가 일반적으로 데이터를 안전하게 전달한다고 신뢰할 수 있는 origin입니다.

이 알고리즘은 특정 호스트, 스킴, origin을 잠재적으로 신뢰할 수 있는 것으로 간주하며, 전통적인 의미에서 인증 및 암호화되지 않을 수도 있습니다. 특히, 사용자 에이전트는 file URL을 잠재적으로 신뢰할 수 있는 것으로 처리해야 합니다. 원칙적으로 사용자 에이전트가 로컬 파일을 신뢰하지 않을 수도 있지만, 런타임에 사용자 에이전트가 가질 수 있는 정보에 근거해 해당 리소스는 디스크에서 사용자 에이전트로 안전하게 전송된 것으로 보입니다. 또한, 이러한 리소스를 잠재적으로 신뢰할 수 있는 것으로 처리하는 것은 애플리케이션을 공개 전 개발 중인 개발자에게 편리합니다.

하지만 이 개발자 친화성에는 위험이 따릅니다. 보안을 우선하는 사용자 에이전트는 file을 제외하는 방식으로 더 엄격하게 신뢰를 할당할 수도 있습니다.

반면, 사용자 에이전트는 app: 또는 chrome-extension: 등 기타 벤더 고유의 URL 스킴에도 신뢰를 확장할 수 있으며, a priori 신뢰할 수 있다고 판단할 수 있습니다(자세한 사항은 § 7.1 패키지 애플리케이션 참조).

origin(origin)이 주어졌을 때, 다음 알고리즘은 적절히 "잠재적으로 신뢰할 수 있음" 또는 "신뢰할 수 없음"을 반환합니다.

만약 origin이 불투명 origin이라면, "신뢰할 수 없음"을 반환합니다.
단언: origin은 튜플 origin입니다.
만약 origin의 스킴이 "https" 또는 "wss"라면, "잠재적으로 신뢰할 수 있음"을 반환합니다.

참고: 이는 a priori 인증된 URL 개념과 유사합니다. [MIX].
만약 origin의 호스트가 127.0.0.0/8 또는 ::1/128 CIDR 표기와 일치한다면 [RFC4632], "잠재적으로 신뢰할 수 있음"을 반환합니다.
만약 사용자 에이전트가 [let-localhost-be-localhost]의 네임 해석 규칙을 준수하고 다음 중 하나가 참이라면:
- origin의 호스트가 "localhost" 또는 "localhost."인 경우
- origin의 호스트가 ".localhost" 또는 ".localhost."로 끝나는 경우
이 경우 "잠재적으로 신뢰할 수 있음"을 반환합니다.

참고: 자세한 요구사항은 § 5.2 localhost를 참조하세요.
만약 origin의 스킴이 "file"이면, "잠재적으로 신뢰할 수 있음"을 반환합니다.
만약 origin의 스킴이 사용자 에이전트가 인증된 것으로 간주하는 컴포넌트라면, "잠재적으로 신뢰할 수 있음"을 반환합니다.

참고: 자세한 내용은 § 7.1 패키지 애플리케이션을 참조하세요.
만약 origin이 신뢰할 수 있는 origin으로 구성된 경우, "잠재적으로 신뢰할 수 있음"을 반환합니다.

참고: 자세한 내용은 § 7.2 개발 환경을 참조하세요.
"신뢰할 수 없음"을 반환합니다.

참고: origin의 도메인이나 포트는 보안 컨텍스트로 간주되는지 여부에 영향을 주지 않습니다.

3.2. `url`이 잠재적으로 신뢰할 수 있는가?

잠재적으로 신뢰할 수 있는 URL은 생성자 컨텍스트를 상속받는(about:blank, about:srcdoc, data) 것이거나 origin이 잠재적으로 신뢰할 수 있는 origin인 것입니다. URL 레코드(url)가 주어졌을 때, 다음 알고리즘은 적절히 "잠재적으로 신뢰할 수 있음" 또는 "신뢰할 수 없음"을 반환합니다:

url이 "about:blank" 또는 "about:srcdoc"이면, "잠재적으로 신뢰할 수 있음"을 반환합니다.
url의 스킴이 "data"이면, "잠재적으로 신뢰할 수 있음"을 반환합니다.
url의 origin에 대해 § 3.1 origin이 잠재적으로 신뢰할 수 있는가?를 실행한 결과를 반환합니다.

참고: blob: URL의 origin은 생성된 컨텍스트의 origin입니다. 따라서 신뢰할 수 있는 origin에서 생성된 blob은 잠재적으로 신뢰할 수 있습니다.

4. 위협 모델 및 위험

이 섹션은 규범적인 내용이 아닙니다.

4.1. 위협 모델

인증되지 않은 출처에 권한을 부여하는 것은 네트워크 공격자가 있는 상황에서는 모든 출처에 권한을 부여하는 것과 동일합니다. 인터넷의 상태를 고려할 때, 우리는 실제로 네트워크 공격자가 존재한다고 가정해야 합니다. 일반적으로 네트워크 공격자는 수동적 공격자와 능동적 공격자 두 가지 유형으로 나뉩니다.

4.1.1. 수동적 네트워크 공격자

"수동적 네트워크 공격자"는 트래픽 흐름을 관찰할 수 있지만, 이 명세서가 다루는 계층에서 트래픽을 수정할 능력이 없거나 그렇게 하지 않기로 선택한 주체입니다.

이러한 방식의 네트워크 감시는 "통신 당사자의 의도를 당사자의 동의 없이 저해"하며, "가장 악의적인 행위자를 방어하는 동시에 다른 행위자(아무리 선의라고 하더라도)의 감시를 허용할 수 없다"고 할 수 있습니다. [RFC7258] 따라서, 이 문서에 정의된 알고리즘은 애플리케이션 계층에서 데이터의 프라이버시를 제공하는 메커니즘을 요구하며, 단순히 무결성만을 제공해서는 안 됩니다.

4.1.2. 능동적 네트워크 공격자

"능동적 네트워크 공격자"는 "수동적 네트워크 공격자"의 모든 능력을 가지며, 추가적으로 네트워크를 통과하는 모든 데이터를 수정, 차단 또는 재전송할 수 있습니다. 이러한 능력은 공용 무선 네트워크에 참여하거나 서비스를 제공하는 손상된 장치부터, 인터넷 서비스 제공업자가 금융 이익을 위해 트래픽을 조작하며 간접적으로 보안 및 프라이버시 취약점을 유발하는 경우([VERIZON] 및 [COMCAST]가 최근 예시), 특정 사용자, 조직 또는 전체 인구를 대상으로 보안이나 프라이버시를 직접 침해하려는 주체까지 다양한 수준의 잠재적 적대자에게 있습니다.

4.2. 상위 컨텍스트 위험

secure context 알고리즘은 특정 컨텍스트의 모든 상위 요소를 검사하여 해당 컨텍스트 자체가 안전한지 여부를 판단합니다. 그렇다면 왜 안전하게 전달된 문서가 iframe에 있을 때, 그 자체로 안전하다고 여기지 않을까요?

간단히 말해, 이 모델은 악용을 유발할 수 있기 때문입니다. Chrome의 [WEBCRYPTOAPI] 구현은 API를 안전한 컨텍스트에만 제한하는 초기 실험이었으며, 컨텍스트의 상위 요소를 검사하지 않았습니다. 리소스 자체가 안전하게 전달되면 안전하게 사용된다고 가정했지만, 실제로는 Netflix와 같은 업체들이 iframe 및 postMessage() 기반의 셈(shim)을 만들어 비안전한 컨텍스트에 API를 노출했습니다. 이러한 제한은 비안전한 접근을 늦추는 방해물에 불과했으며, 접근 자체를 막는 데는 효과적이지 않았습니다.

이 문서의 알고리즘이 비안전한 컨텍스트와 secure context를 완전히 분리하지는 않지만(§ 5.1 불완전한 분리에서 논의됨), 상위 요소 검사는 인증, 기밀성, 무결성에 대한 보장을 위해 상당히 견고한 보호를 제공합니다.

4.3. 비안전한 컨텍스트와 관련된 위험

사용자의 보안 또는 프라이버시에 명확한 영향을 미치는 웹 플랫폼 기능은 위에서 언급한 위협으로부터 방어하기 위해 secure context에서만 사용할 수 있어야 합니다. 비안전한 컨텍스트에서 제공되는 기능은 네트워크 공격자에게 이러한 기능을 노출할 위험이 있습니다:

민감한 데이터(개인 식별 정보, 자격 증명, 결제 수단 등)를 읽거나 수정하는 기능. [CREDENTIAL-MANAGEMENT-1]은 민감한 데이터를 처리하는 API의 예시입니다.
사용자의 장치에서 센서 입력(카메라, 마이크, GPS 등, 그 외에 가속도계와 같이 덜 위험해 보이는 센서 포함)을 읽거나 수정하는 기능. [GEOLOCATION-API] 및 [MEDIACAPTURE-STREAMS]는 센서 입력을 사용하는 기능의 역사적 예시입니다.
사용자가 접근할 수 있는 다른 장치에 대한 정보를 접근하는 기능. [DISCOVERY-API] 및 [WEB-BLUETOOTH]가 좋은 예입니다.
임시 또는 영구 식별자를 사용하여 사용자를 추적하는 기능(예: window.sessionStorage처럼 일정 기간 후 재설정되는 식별자, 사용자가 직접 재설정할 수 있는 식별자(예: [ENCRYPTED-MEDIA], 쿠키 [RFC6265], [IndexedDB]), 사용자가 쉽게 재설정할 수 없는 하드웨어의 식별 기능 등).
출처(origin)에 대해 브라우징 세션 간에 상태를 도입하는 기능. [SERVICE-WORKERS]가 대표적인 예시입니다.
사용자의 에이전트(브라우저)의 UI를 조작하여 사용자의 컨텍스트 이해에 필요한 정보를 숨기거나 조작하는 기능. [FULLSCREEN]이 좋은 예입니다.
사용자의 권한이 필요한 기능을 도입하는 기능.

이 목록은 완전하지 않지만, 명세를 작성하거나 구현할 때 고려해야 할 위험 유형에 대한 이해를 제공합니다.

참고: 기능 자체를 secure context로 제한하는 것이 중요하지만, 그러한 정보를 전달하는 수단(예: 새로운 네트워크 접근 메커니즘이나 네트워크 데이터에 접근할 수 있는 기타 일반 기능) 역시 동일하게 민감하다는 점을 잊지 말아야 합니다.

5. 보안 고려 사항

5.1. 불완전한 분리

이 문서의 secure context 정의는 한 출처(origin)에서 "안전한" 뷰와 "비안전한" 뷰를 완전히 분리하지 않습니다. localStorage/sessionStorage, storage 이벤트, BroadcastChannel 등 점점 더 난해한 방식으로 정보 유출(Exfiltration)이 여전히 가능합니다.

5.2. `localhost`

[RFC6761]의 6.3절에서는 localhost. 및 .localhost. 내의 이름 해석을 특별하게 다루며, 로컬 리졸버가 이들을 특별히 처리할 것을 권장합니다(SHOULD/MAY). 그러나 실제로는 리졸버가 이러한 권고를 무시하고 여러 상황에서 localhost를 네트워크로 해석 요청하는 경우도 있습니다.

이러한 불확실성을 고려하여, 사용자 에이전트는 잠재적으로 신뢰할 수 있는 출처로 localhost 이름을 처리할 수 있지만, 반드시 [let-localhost-be-localhost]에서 규정한 localhost 이름 해석 규칙(즉, localhost가 비루프백 주소로 해석되지 않도록 보장)을 준수하는 경우에 한합니다.

6. 프라이버시 고려 사항

이 문서의 secure context 정의 자체는 프라이버시에 직접적인 영향을 미치지 않습니다. 그러나, 무결성, 진위성, 기밀성에 대한 특정 보장을 할 수 있는 컨텍스트에 기능을 제한함으로써 프라이버시와 관련된 기능이 안전하게 동작하도록 할 수 있습니다.

프라이버시 관점에서, 명세 작성자는 자신이 정의하는 기능에 대해 안전한 컨텍스트를 요구하도록 고려할 것을 권장합니다.

7. 구현 고려 사항

7.1. 패키지 애플리케이션

패키지 애플리케이션을 지원하는 사용자 에이전트는, 그 내용이 사용자 에이전트에 의해 인증되는 특정 URL 스킴을 "안전"하다고 간주할 수 있습니다(MAY). 예를 들어, FirefoxOS 애플리케이션 리소스는 scheme이 app:인 URL로 참조됩니다. Chrome의 확장 프로그램과 앱 역시 chrome-extension: 스킴에 존재합니다. 이러한 경우, 신뢰할 수 있는 출처로 합리적으로 간주할 수 있습니다.

7.2. 개발 환경

루프백이 아닌 호스트에서 스테이징 서버를 실행하는 개발자를 지원하기 위해, 사용자 에이전트는 § 3.1 출처가 잠재적으로 신뢰할 수 있는가?에서 "신뢰할 수 없음"을 반환하는 경우에도 사용자가 특정 출처 집합을 신뢰할 수 있도록 구성할 수 있습니다(MAY).

7.3. 신규 기능 제한

이 섹션은 규범적인 내용이 아닙니다.

신규 기능에 대한 명세를 작성할 때, 저자와 편집자에게 민감한 API를 secure context 검사로 보호할 것을 권장합니다. 예를 들어, 다음과 같이 작성할 수 있습니다:

current settings object가 secure context가 아닌 경우:
1. [적절한 내용을 삽입: 예를 들어 Promise를 SecurityError로 reject하거나, 에러 콜백을 호출하거나, 권한 요청을 거부하는 등].

저자는 민감한 API가 [SecureContext] 속성으로 보호되어 secure context에서만 노출되도록 할 수도 있습니다.

[SecureContext]
interface SensitiveFeature {
  Promise<double> getTheSecretDouble();
};

// Or:

interface AnotherSensitiveFeature {
  [SecureContext] void doThatPowerfulThing();
};

7.4. 레거시 기능 제한

이 섹션은 규범적인 내용이 아닙니다.

위 목록에는 현재 비안전한 채널을 통해 웹에서 사용할 수 있는 기존 기능도 포함되어 있습니다. 이러한 레거시 기능 역시 최대한 빠르게 secure context를 요구하도록 수정할 것을 권장합니다. [W3C-PROCESS].

해당 기능이 널리 구현되지 않았다면, 명세를 즉시 수정하여 secure context 제한을 포함할 것을 권장합니다.
해당 기능이 널리 구현되었지만, 아직 널리 사용되지는 않는 경우, 명세와 구현에 § 7.3 신규 기능 제한에서 설명한 검사를 추가하여 secure context로 빠르게 제한할 것을 권장합니다. 명세 역시 이에 맞게 수정해야 합니다.
해당 기능이 널리 사용되고 있는 경우, 기존 기능을 폐지(deprecate)하는 것이 권장되며, 명세에서는 본 문서의 제한을 준수하지 않음을 명시하고, 준수 버전 제공 및 기존 사용자 이전 계획을 개발해야 합니다. 수정

7.4.1. 예시: 위치 정보

[GEOLOCATION-API]는 이러한 기능의 구체적인 예시로, 많은 비안전한 사이트에서 널리 구현되고 사용됩니다. 합리적인 개선 경로는 다음과 같을 수 있습니다:

명세를 수정하여, getCurrentPosition() 및 watchPosition() 알고리즘 실행 전에 secure context 검사를 추가합니다.

current settings object가 secure context가 아니면 알고리즘을 중단하고 errorCallback을 PERMISSION_DENIED 코드로 호출해야 합니다.
사용자 에이전트는 비안전한 컨텍스트에 대한 API 비활성화 계획을 명확히 발표하고(예: 콘솔 메시지 등으로) 개발자에게 경고해야 합니다.
플래그 데이 이전에는 사이트 저자가 코드 수정을 인지할 수 있도록 폐지 일정을 사전에 알리고, 그동안 사용자 보호를 위해 다음과 같은 방안을 포함할 수 있습니다:
1. 비안전한 출처에 영구적인 권한 부여를 허용하지 않음
2. 비안전한 출처에 대해 API 정확도를 낮춤(예: 항상 도시 수준 데이터만 반환)
  1. UI를 수정하여 사용자와 사이트 저자에게 위험을 알림

8. 감사의 말

이 문서는 주로 Chrome 보안 팀의 [POWERFUL-NEW-FEATURES] 작업을 기반으로 작성되었습니다. Chris Palmer, Ryan Sleevi, David Dorwin이 특히 많은 기여를 했으며, Anne van Kesteren, Jonathan Watt, Boris Zbarsky, Henri Sivonen도 매우 유익한 피드백을 제공해주셨습니다.

보안 컨텍스트

요약

이 문서의 상태

1. 소개

1.1. 최상위 문서

1.2. 프레임된 문서

1.3. 웹 워커

1.4. 공유 워커

1.5. 서비스 워커

2. 프레임워크

2.1. WebIDL과의 통합

2.2. HTML과의 통합

2.2.1. 공유 워커

2.2.2. 기능 감지

2.2.3. 보안 및 비보안 컨텍스트

3. 알고리즘

3.1. origin이 잠재적으로 신뢰할 수 있는가?

3.2. url이 잠재적으로 신뢰할 수 있는가?

4. 위협 모델 및 위험

4.1. 위협 모델

4.1.1. 수동적 네트워크 공격자

4.1.2. 능동적 네트워크 공격자

4.2. 상위 컨텍스트 위험

4.3. 비안전한 컨텍스트와 관련된 위험

5. 보안 고려 사항

5.1. 불완전한 분리

5.2. localhost

6. 프라이버시 고려 사항

7. 구현 고려 사항

7.1. 패키지 애플리케이션

7.2. 개발 환경

7.3. 신규 기능 제한

7.4. 레거시 기능 제한

7.4.1. 예시: 위치 정보

8. 감사의 말

색인

이 명세서에서 정의한 용어

참고 문서에서 정의된 용어

참고 문헌

규범적 참고 문헌

참고용 참고 문헌

3.1. `origin`이 잠재적으로 신뢰할 수 있는가?

3.2. `url`이 잠재적으로 신뢰할 수 있는가?

5.2. `localhost`