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

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

Eiji Kitamura

업데이트

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

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

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

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

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

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

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

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

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

COOP 및 COEP 통합

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

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

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

DevTools에서 창 오프너와 창을 여는 사용자가 별도의 탐색 컨텍스트 그룹에 있는지 확인할 수 있습니다.

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> 등에 적용됩니다.

3. COEP 보고서 전용 HTTP 헤더를 사용하여 삽입된 리소스 평가

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

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

4. COEP 사용 설정

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

self.crossOriginIsolated를 사용하여 격리가 성공했는지 확인

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

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

이미지와 같이 화면에 렌더링되는 리소스의 경우 요청이 차단되고 페이지에 누락된 이미지가 표시되기 때문에 COEP 문제를 매우 쉽게 감지할 수 있습니다. 하지만 스크립트나 스타일과 같이 시각적 영향이 없는 리소스의 경우 COEP 문제를 발견하지 못할 수 있습니다. 이런 경우에는 DevTools Network 패널을 사용하세요. COEP에 문제가 있으면 상태 열에 (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep)이 표시됩니다.

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

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

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

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

Reporting API를 사용하여 문제 관찰

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

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"
}]

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()를 사용하여 웹페이지의 총 메모리 사용량을 모니터링합니다.