팝업과 상호작용하는 동안 교차 출처 격리 및 교차 사이트 유출을 방지하세요.
교차 출처 오프너 정책(COOP)에 새로운 값(restrict-properties)을 사용할 수 있습니다. 보안 이점을 제공하고 교차 출처 격리를 더 쉽게 채택할 수 있으며, 사이트가 결제, 인증 또는 기타 사용 사례에 관해 서드 파티 팝업과 상호작용할 수 있습니다.
restrict-properties을(를) 사용해 보려면 Chrome 116부터 시작되는 오리진 트라이얼에 참여하세요.
restrict-properties를 사용해야 하는 이유
restrict-properties에는 두 가지 주요 사용 사례가 있습니다.
- 중단 없이 크로스 사이트 유출을 방지합니다.
- 사이트를 교차 출처 격리합니다.
중단 없이 크로스 사이트 유출 방지
기본적으로 모든 웹사이트에서 애플리케이션을 팝업에서 열고 참조를 가져올 수 있습니다.
악성 웹사이트는 이를 악용하여 크로스 사이트 유출과 같은 공격을 실행할 수 있습니다.
이 위험을 완화하려면 Cross-Origin-Opener-Policy (COOP) 헤더를 사용하면 됩니다.
지금까지는 Cross-Origin-Opener-Policy에 적용할 수 있는 옵션이 제한되었습니다. 다음 중 한 가지 방법을 사용할 수 있습니다.
- 팝업과의 모든 교차 출처 상호작용을 차단하는
same-origin,를 설정합니다. - 팝업에서 사이트를 여는 모든 교차 출처 상호작용을 차단하는
same-origin-allow-popups를 설정합니다. - 팝업과의 모든 교차 출처 상호작용을 허용하는
unsafe-none를 설정합니다.
이로 인해 웹사이트를 팝업에서 열어야 하고 오프너와 상호작용하여 COOP를 적용할 수 없었습니다. 이로 인해 싱글 사인온(SSO) 및 결제와 같은 주요 사용 사례가 크로스 사이트 유출로부터 보호되지 않았습니다.
Cross-Origin-Opener-Policy: restrict-properties가 이 문제를 해결합니다.
restrict-properties를 사용하면 프레임 수 및 기타 교차 사이트 유출 공격에 사용할 수 있는 속성을 사용할 수 없지만 postMessage 및 closed를 통한 창 간의 기본 통신은 허용됩니다.
이렇게 하면 사이트의 보안을 강화하는 동시에 주요 사용 사례를 유지할 수 있습니다. 예를 들면 다음과 같습니다.
- 팝업에서 서비스를 제공하는 경우
Cross-Origin-Opener-Policy: restrict-properties를 설정하면 다양한 크로스 사이트 유출 공격으로부터 보호할 수 있습니다. 이전에 열 수 있었던 모든 페이지는 계속 열 수 있습니다. - 교차 출처 팝업에 액세스해야 하는 경우
Cross-Origin-Opener-Policy: restrict-properties를 설정하면 사이트가 iframe 계산으로부터 보호됩니다. 오늘 열 수 있는 동일한 팝업 집합을 열 수 있습니다. - 여는 사람과 여는 사람이 모두 헤더를 설정했고 페이지가 교차 출처인 경우 페이지 중 하나가 헤더를 설정한 것과 유사하게 작동합니다. 출처가 동일하면 전체 액세스 권한이 부여됩니다.
사이트의 교차 출처 분리
교차 출처 격리가 필요한 이유
일부 웹 API는 스펙터와 같은 부채널 공격의 위험을 높입니다. 이러한 위험을 완화하기 위해 브라우저는 교차 출처 격리라는 선택 기반의 격리 환경을 제공합니다. 교차 출처 분리 상태를 사용하면 웹페이지에서는 더 나은 해상도의 SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), 높은 정밀도 타이머와 같은 권한 있는 기능을 사용할 수 있으며 출처가 선택되지 않은 경우 출처를 격리할 수 있습니다.
지금까지는 이러한 API를 사용하려면 Cross-Origin-Opener-Policy:
same-origin를 설정해야 했습니다. 하지만 이렇게 하면 싱글 사인온(SSO) 및 결제와 같은 필요한 교차 출처 팝업 흐름이 중단됩니다.
이제 Cross-Origin-Opener-Policy: same-origin 대신 Cross-Origin-Opener-Policy: restrict-properties를 사용하여 교차 출처 분리를 사용 설정할 수 있습니다.
Opener 관계를 끊는 대신 window.postMessage() 및 window.closed의 최소한의 통신 하위 집합으로만 제한합니다.
다음 두 헤더를 사용하여 교차 출처 격리를 사용 설정할 수 있습니다.
Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp
또는
Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless
COEP: credentialless를 사용하여 CORP 헤더 없이 교차 출처 리소스 로드에서 credentialless에 대해 자세히 알아보세요.
데모
이 교차 출처 격리 데모에서 다양한 헤더 옵션을 사용해 보세요.
오리진 트라이얼 실험
Cross-Origin-Opener-Policy: restrict-properties로 실험하려면 오리진 트라이얼을 선택하세요.
브라우저 지원
Cross-Origin-Opener-Policy: restrict-properties는 현재 Chrome에서만 지원됩니다. 다른 브라우저는 표준화를 위한 논의에 적극적으로 참여하고 있습니다.
FAQ
웹사이트에서 동일 출처 팝업과 통신해야 합니다. 교차 출처 격리를 사용 설정하려면 COOP: restrict-properties를 사용해야 하나요?
팝업과 기본 페이지에서 모두 COOP: restrict-properties를 설정해도 제한이 발생하지 않습니다. 팝업에서만 또는 기본 페이지에서만 설정하면 출처가 동일하더라도 오프너에서 postMessage 및 closed 이외의 속성에 액세스할 수 없습니다.
허용되는 속성 집합이 고정되어 있나요?
지금까지의 의견에 따르면 window.postMessage 및 window.closed는 대부분의 워크플로에 충분한 것으로 의심되지만 아직 다른 속성에 개방하는 것을 고려하고 있습니다. postMessage 및 closed만 사용하여 해결할 수 없는 사용 사례가 있다면 실험용 인텐트 스레드에 의견을 남겨주세요.