COOP 및 COEP를 사용하여 웹사이트를 '교차 출처 분리'했습니다.

COOP 및 COEP를 사용하여 교차 출처 격리 환경을 설정하고 SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), 고해상도 타이머와 같은 강력한 기능을 더 나은 정밀도로 사용 설정합니다.

Eiji Kitamura

주의: Chrome 데스크톱의 SharedArrayBuffer에는 Chrome 92부터 교차 출처 격리가 필요합니다. Android Chrome 88 및 데스크톱 Chrome 92의 SharedArrayBuffer 업데이트에서 자세히 알아보세요.

업데이트

• 2022년 6월 21일: 교차 출처 격리가 사용 설정된 경우에도 작업자 스크립트에 주의해야 합니다. 설명이 추가되었습니다.
• 2021년 8월 5일: JS Self-Profiling API가 교차 출처 격리가 필요한 API 중 하나로 언급되었지만 최근 방향 변경을 반영하여 삭제되었습니다.
• 2021년 5월 6일: 신고된 의견 및 문제를 바탕으로 교차 출처 격리되지 않은 사이트에서 SharedArrayBuffer 사용이 Chrome M92에서 제한되도록 타임라인을 조정하기로 결정했습니다.
• 2021년 4월 16일: 새로운 COEP 인증서 없는 모드 및 교차 출처 격리를 위한 완화된 조건으로 COOP same-origin-allow-popups에 관한 메모를 추가했습니다.
• 2021년 3월 5일: SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), 디버깅 기능의 제한사항이 삭제되었으며 이제 Chrome 89에서 완전히 사용 설정됩니다. 향후 더 높은 정밀도를 제공할 performance.now() 및 performance.timeOrigin 기능을 추가했습니다.
• 2021년 2월 19일: DevTools의 기능 정책 allow="cross-origin-isolated" 및 디버깅 기능에 관한 메모를 추가했습니다.
• 2020년 10월 15일: self.crossOriginIsolated는 Chrome 87부터 사용할 수 있습니다. 이를 반영하여 self.crossOriginIsolated가 true를 반환하면 document.domain는 변경할 수 없습니다. performance.measureUserAgentSpecificMemory()의 오리진 트라이얼이 종료되며 Chrome 89에서 기본적으로 사용 설정됩니다. Android Chrome의 공유 배열 버퍼는 Chrome 88부터 사용할 수 있습니다.

일부 웹 API는 Spectre와 같은 측면 채널 공격의 위험을 증가시킵니다. 이러한 위험을 완화하기 위해 브라우저는 교차 출처 격리라는 선택 기반 격리 환경을 제공합니다. 교차 출처 격리 상태를 사용하면 웹페이지에서 다음과 같은 권한이 있는 기능을 사용할 수 있습니다.

교차 출처 분리 상태에서 사용할 수 있는 기능입니다.

API	설명
SharedArrayBuffer	WebAssembly 스레드에 필요합니다. 이 기능은 Android Chrome 88부터 사용할 수 있습니다. 데스크톱 버전은 현재 사이트 격리를 사용하여 기본적으로 사용 설정되지만 교차 출처 분리 상태가 필요하며 Chrome 92에서는 기본적으로 사용 중지됩니다.
performance.measureUserAgentSpecificMemory()	Chrome 89부터 사용 가능합니다.
performance.now(), performance.timeOrigin	현재 많은 브라우저에서 해상도가 100마이크로초 이상으로 제한된 상태로 사용할 수 있습니다. 교차 출처 격리를 사용하면 해상도가 5마이크로초 이상일 수 있습니다.

교차 출처 격리 상태는 document.domain의 수정도 방지합니다. document.domain를 변경할 수 있으면 동일 사이트 문서 간에 통신할 수 있으며 동일 출처 정책의 허점으로 간주되었습니다.

교차 출처 격리 상태를 선택하려면 기본 문서에서 다음 HTTP 헤더를 전송해야 합니다.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

이러한 헤더는 교차 출처 문서에서 로드하도록 선택하지 않은 리소스 또는 iframe의 로드를 차단하도록 브라우저에 지시하고 교차 출처 창이 문서와 직접 상호작용하는 것을 방지합니다. 즉, 교차 출처에서 로드되는 이러한 리소스에는 선택이 필요합니다.

self.crossOriginIsolated를 검사하여 웹페이지가 교차 출처 격리 상태인지 확인할 수 있습니다.

이 도움말에서는 이러한 새 헤더를 사용하는 방법을 설명합니다. 후속 도움말에서 자세한 배경과 맥락을 제공해 드리겠습니다.

참고: 이 도움말은 브라우저 플랫폼 전반에서 더 정확하고 안정적인 방식으로 SharedArrayBuffer, WebAssembly 스레드, performance.measureUserAgentSpecificMemory() 또는 고해상도 타이머를 사용할 수 있도록 웹사이트를 준비하려는 사용자를 대상으로 합니다.

핵심 용어: 이 도움말에서는 비슷한 용어를 많이 사용합니다. 더 명확하게 이해하려면 먼저 다음을 정의해 보겠습니다. * COEP: 교차 출처 삽입자 정책 * COOP: 교차 출처 오프너 정책 * CORP: 교차 출처 리소스 정책 * CORS: 교차 출처 리소스 공유 * CORB: 교차 출처 읽기 차단

COOP 및 COEP를 배포하여 웹사이트를 교차 출처 격리 처리

참고: 교차 출처 분리 사용 설정 가이드에서 교차 출처 분리를 사용 설정하는 실용적인 단계를 알아보세요.

COOP 및 COEP 통합

1. 최상위 문서에서 Cross-Origin-Opener-Policy: same-origin 헤더 설정

최상위 문서에서 COOP: same-origin를 사용 설정하면 동일한 출처의 창과 문서에서 연 창은 동일한 COOP 설정으로 동일한 출처에 있지 않는 한 별도의 탐색 컨텍스트 그룹을 갖게 됩니다. 따라서 열린 창에 격리가 적용되고 두 창 간의 상호 통신이 사용 중지됩니다.

주의: 이렇게 하면 OAuth 및 결제와 같이 교차 출처 창 상호작용이 필요한 통합이 중단됩니다. 이 문제를 완화하기 위해 Cross-Origin-Opener-Policy: same-origin-allow-popups에 교차 출처 격리를 사용 설정하기 위한 조건 완화를 모색하고 있습니다. 이렇게 하면 자동으로 열리는 창과의 통신이 가능합니다. 교차 출처 격리를 사용 설정하고 싶지만 이 문제로 인해 차단된 경우 출처 체험판에 등록하고 새 조건을 사용할 수 있을 때까지 기다리는 것이 좋습니다. 이 문제가 안전하게 해결될 때까지는 오리진 체험판을 종료할 계획이 없습니다.

탐색 컨텍스트 그룹은 서로 참조할 수 있는 창의 집합입니다. 예를 들어 <iframe>를 통해 삽입된 최상위 문서와 하위 문서가 있습니다. 웹사이트 (https://a.example)가 팝업 창 (https://b.example)을 열면 opener 창과 팝업 창이 동일한 탐색 컨텍스트를 공유하므로 window.opener와 같은 DOM API를 통해 서로 액세스할 수 있습니다.

창 열기 도구와 열기 대상이 DevTools의 별도 탐색 컨텍스트 그룹에 있는지 확인할 수 있습니다.

사용해 보기: 다양한 COOP 매개변수의 영향을 확인합니다.

2. 리소스에 CORP 또는 CORS가 사용 설정되어 있는지 확인

페이지의 모든 리소스가 CORP 또는 CORS HTTP 헤더로 로드되는지 확인합니다. 이 단계는 4단계, COEP 사용 설정에 필요합니다.

리소스의 성격에 따라 취해야 할 조치는 다음과 같습니다.

• 리소스가 동일한 출처에서만 로드될 것으로 예상되는 경우 Cross-Origin-Resource-Policy: same-origin 헤더를 설정합니다.
• 리소스가 동일한 사이트에서만 로드되지만 교차 출처인 경우 Cross-Origin-Resource-Policy: same-site 헤더를 설정합니다.
• 리소스가 개발자가 제어하는 교차 출처에서 로드되는 경우 가능하면 Cross-Origin-Resource-Policy: cross-origin 헤더를 설정합니다.
• 내가 제어할 수 없는 교차 출처 리소스의 경우 다음을 실행합니다.
  • 리소스가 CORS로 제공되는 경우 로드 HTML 태그에 crossorigin 속성을 사용합니다. (예: <img src="***" crossorigin>)
  • 리소스 소유자에게 CORS 또는 CORP를 지원해 달라고 요청합니다.
• iframe의 경우 위의 원칙을 따르고 Cross-Origin-Resource-Policy: cross-origin (또는 컨텍스트에 따라 same-site, same-origin)를 설정합니다.
• WebWorker로 로드된 스크립트는 동일 출처에서 제공되어야 하므로 CORP 또는 CORS 헤더가 필요하지 않습니다.
• COEP: require-corp로 제공되는 문서 또는 작업자의 경우 CORS 없이 로드된 교차 출처 하위 리소스는 삽입을 선택하도록 Cross-Origin-Resource-Policy: cross-origin 헤더를 설정해야 합니다. 예를 들어 <script>, importScripts, <link>, <video>, <iframe> 등에 적용됩니다.

allow="cross-origin-isolated" 권한 정책을 <iframe> 태그에 적용하고 이 문서에 설명된 것과 동일한 조건을 충족하여 iframe 내에 삽입된 문서에서 교차 출처 격리를 사용 설정할 수 있습니다. 상위 프레임과 하위 프레임을 포함한 문서의 전체 체이닝도 교차 출처 격리되어야 합니다.

핵심 용어: '동일 사이트'와 '동일 출처'의 차이를 이해하는 것이 중요합니다. 동일 사이트 및 동일 출처 이해하기에서 차이점을 알아보세요.

3. COEP Report-Only HTTP 헤더를 사용하여 삽입된 리소스 평가

COEP를 완전히 사용 설정하기 전에 Cross-Origin-Embedder-Policy-Report-Only 헤더를 사용하여 정책이 실제로 작동하는지 확인하는 예행 연습을 실행할 수 있습니다. 삽입된 콘텐츠를 차단하지 않아도 신고가 접수됩니다.

최상위 문서, iframe, 작업자 스크립트를 포함한 모든 문서에 이를 재귀적으로 적용합니다. Report-Only HTTP 헤더에 관한 자세한 내용은 Reporting API를 사용하여 문제 관찰을 참고하세요.

4. COEP 사용 설정

모든 것이 작동하고 모든 리소스를 성공적으로 로드할 수 있음을 확인한 후 iframe 및 worker 스크립트를 통해 삽입된 문서를 포함한 모든 문서에서 Cross-Origin-Embedder-Policy-Report-Only 헤더를 동일한 값으로 Cross-Origin-Embedder-Policy 헤더로 전환합니다.

해 보기: 다양한 COEP / CORP 매개변수의 영향을 확인합니다.

참고: Squoosh (이미지 최적화 PWA)는 이제 Android Chrome에서도 COOP / COEP를 사용하여 Wasm 스레드 (및 공유 배열 버퍼)에 액세스합니다.

주의: 교차 출처 격리는 모든 하위 리소스를 명시적으로 선택해야 하므로 Cross-Origin-Resource-Policy를 대규모로 배포하는 방법을 모색하고 있습니다. 이에 반대되는 방향으로 가자는 아이디어를 생각해 냈습니다. 모든 사용자 인증 정보를 제거하여 CORP 헤더 없이 리소스를 로드할 수 있는 새로운 COEP '인증 정보 없음' 모드입니다. 이렇게 하면 하위 리소스가 Cross-Origin-Resource-Policy 헤더를 전송하는지 확인하는 부담이 줄어들기를 바랍니다. 그러나 credentialless 모드는 Chrome 버전 96부터 사용할 수 있지만 아직 다른 브라우저에서는 지원되지 않으므로 일부 개발자는 COOP 또는 COEP를 배포하는 데 어려움을 겪을 수 있습니다. 아직 교차 출처 격리를 사용 설정하지 않으려면 출처 체험판에 등록하고 더 많은 브라우저에서 credentialless를 사용할 수 있을 때까지 기다리는 것이 좋습니다.

self.crossOriginIsolated로 격리가 완료되었는지 확인

self.crossOriginIsolated 속성은 웹페이지가 교차 출처 격리 상태에 있고 모든 리소스와 창이 동일한 탐색 컨텍스트 그룹 내에 격리되어 있으면 true을 반환합니다. 이 API를 사용하여 브라우징 컨텍스트 그룹을 성공적으로 격리하고 performance.measureUserAgentSpecificMemory()와 같은 강력한 기능에 액세스할 수 있는지 확인할 수 있습니다.

Chrome DevTools를 사용하여 문제 디버그

이미지와 같이 화면에 렌더링되는 리소스의 경우 요청이 차단되고 페이지에 이미지 누락이 표시되므로 COEP 문제를 감지하기 쉽습니다. 그러나 스크립트나 스타일과 같이 시각적 영향을 미치지 않는 리소스의 경우 COEP 문제가 눈에 띄지 않을 수 있습니다. 이 경우 DevTools Network 패널을 사용하세요. COEP에 문제가 있는 경우 상태 열에 (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep)가 표시됩니다.

그런 다음 항목을 클릭하여 자세한 내용을 확인할 수 있습니다.

애플리케이션 패널을 통해 iframe 및 팝업 창의 상태를 확인할 수도 있습니다. 왼쪽의 '프레임' 섹션으로 이동하여 '상단'을 펼쳐 리소스 구조의 세부정보를 확인합니다.

SharedArrayBuffer의 사용 가능 여부와 같은 iframe의 상태를 확인할 수 있습니다.

교차 출처 격리 여부와 같은 팝업 창의 상태를 확인할 수도 있습니다.

Reporting API를 사용하여 문제 관찰

Reporting API는 다양한 문제를 감지할 수 있는 또 다른 메커니즘입니다. COEP가 리소스 로드를 차단하거나 COOP가 팝업 창을 격리할 때마다 사용자의 브라우저에 보고서를 전송하도록 Reporting API를 구성할 수 있습니다. Chrome은 버전 69부터 COEP 및 COOP를 비롯한 다양한 용도로 Reporting API를 지원해 왔습니다.

참고: 이미 Report-To 헤더와 함께 Reporting API를 사용 중이신가요? Chrome은 Report-To를 Reporting-Endpoints로 대체하는 Reporting API의 새 버전으로 전환하고 있습니다. 새 버전으로 이전하는 것이 좋습니다. 자세한 내용은 Reporting API v1로 이전을 참고하세요.

Reporting API를 구성하고 보고서를 수신하도록 서버를 설정하는 방법을 알아보려면 Reporting API 사용을 참고하세요.

COEP 보고서 예시

교차 출처 리소스가 차단된 경우 COEP 보고서 페이로드의 예는 다음과 같습니다.

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]

주의: blocked-url는 하위 호환성을 위해 제공되며 궁극적으로 삭제될 예정입니다.

COOP 보고서 예시

팝업 창이 격리된 상태로 열릴 때의 COOP 보고서 페이로드 예시는 다음과 같습니다.

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

서로 다른 탐색 컨텍스트 그룹이 서로 액세스하려고 할 때('보고 전용' 모드에서만) COOP도 보고서를 전송합니다. 예를 들어 postMessage()을 시도할 때의 보고서는 다음과 같습니다.

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

결론

COOP 및 COEP HTTP 헤더를 조합하여 웹페이지를 특수 교차 출처 격리 상태로 선택합니다. self.crossOriginIsolated를 검사하여 웹페이지가 교차 출처 격리 상태인지 확인할 수 있습니다.

이 교차 출처 격리 상태에 새로운 기능이 제공되고 COOP 및 COEP와 관련하여 DevTools가 추가로 개선되면 이 게시물을 계속 업데이트할 예정입니다.

리소스

• 강력한 기능을 사용하려면 '교차 출처 격리'가 필요한 이유
• 교차 출처 분리 사용 설정 가이드
• Android Chrome 88 및 데스크톱 Chrome 92의 SharedArrayBuffer 업데이트
• measureUserAgentSpecificMemory()를 사용하여 웹페이지의 총 메모리 사용량 모니터링