
Cross-Origin-Opener-Policy 기준 정리
Cross-Origin-Opener-Policy(COOP)는 새 탭이나 팝업으로 열린 최상위 문서를 현재 문서와 같은 browsing context group에 둘지, 분리된 그룹으로 보낼지 제어하는 HTTP 응답 헤더다. 2026년 6월 3일 기준 MDN과 WHATWG HTML Standard를 보면 값은 unsafe-none, same-origin-allow-popups, same-origin, noopener-allow-popups 네 가지이며, 핵심 목적은 window.opener 관계와 교차 출처 격리 조건을 더 엄격하게 통제하는 데 있다.
실무에서는 COOP를 CORS처럼 네트워크 읽기 권한을 다루는 헤더로 이해하면 방향이 어긋난다. COOP는 문서 간 참조 관계와 브라우징 컨텍스트 그룹 분리를 다루는 정책이다. 이 글은 어떤 값이 어떤 상황에 맞는지와, SharedArrayBuffer 같은 기능을 쓰려면 왜 COEP를 함께 봐야 하는지까지 공식 문서 기준으로 정리한다.
Cross-Origin-Opener-Policy는 무엇을 제어할까?
MDN은 COOP를 Window.open() 또는 새 페이지 내비게이션으로 열린 최상위 문서가 같은 browsing context group(BCG)에 남을지, 새 BCG로 분리될지를 제어하는 헤더로 설명한다. 새 BCG로 분리되면 opener와 opened 문서 사이 참조가 끊어지고, 경우에 따라 프로세스 분리까지 이어질 수 있다.
이 차이는 단순한 탭 동작 문제가 아니다. MDN은 이런 분리가 XS-Leaks 계열 공격 위험을 줄이는 데 도움이 된다고 설명한다. 따라서 COOP의 핵심 판단 기준은 "다른 문서와 스크립트 참조를 유지해야 하는가"와 "현재 문서를 더 강하게 격리해야 하는가"다.
값은 어떻게 다를까?
1. unsafe-none
기본값이다. MDN과 WHATWG 문서 모두 별도 COOP를 적용하지 않으면 이 동작을 따른다고 설명한다. 같은 문맥 그룹 공유를 넓게 허용하므로 호환성은 높지만, opener 관계를 통한 격리 강화 효과는 없다.
2. same-origin
같은 origin이고 같은 정책을 가진 문서끼리만 같은 BCG를 공유한다. MDN은 교차 출처 격리에 필요한 COOP 값으로 same-origin을 제시한다. SharedArrayBuffer처럼 교차 출처 격리 전제가 필요한 기능을 쓰려면 보통 이 값이 기준점이 된다.
3. same-origin-allow-popups
기본 동작은 same-origin에 가깝지만, Window.open()으로 연 문서가 unsafe-none이면 같은 BCG에 남게 할 수 있다. MDN은 OAuth나 결제처럼 신뢰하는 교차 출처 팝업과의 연동이 필요한 경우에 이 값을 예로 든다. 즉 강한 격리가 필요하지만, 특정 팝업 참조는 유지해야 할 때 쓰는 완화형 선택지다.
4. noopener-allow-popups
MDN은 이 값을 opener와 opened 문서의 연결을 더 강하게 끊는 용도로 설명한다. 내비게이션이나 Window.open() 상황에서 새 BCG를 만들도록 유도하므로, 같은 origin 내부에서도 opener 스크립팅을 줄이고 싶은 분리 시나리오에 맞는다.
실무에서는 어떤 값을 먼저 검토할까?
일반 서비스 페이지
외부 팝업과의 스크립트 연동이 필요 없고, 페이지를 더 안전하게 격리하고 싶다면 same-origin이 가장 명확한 출발점이다. 다만 이 값을 넣으면 opener 관계에 의존하던 기존 로그인 흐름이나 도구 연동이 달라질 수 있어 실제 팝업 사용 경로를 먼저 점검해야 한다.
OAuth, 결제, 신뢰된 외부 팝업 연동
외부 인증 창이나 결제 창을 열고 참조를 유지해야 한다면 same-origin-allow-popups가 현실적인 절충안이 될 수 있다. MDN이 이 값을 설명할 때도 신뢰된 교차 출처 문서와의 통합 사례를 든다.
같은 origin 안에서도 opener 관계를 최대한 끊고 싶을 때
관리자 페이지나 민감한 내부 도구처럼 같은 origin의 다른 앱이 열더라도 opener 스크립팅을 최소화하고 싶다면 noopener-allow-popups를 검토할 수 있다. 다만 MDN은 이것만으로 충분한 보안 경계가 생기는 것은 아니라고 명시한다.
교차 출처 격리와는 어떤 관계일까?
MDN의 Window.crossOriginIsolated 문서는 문서가 교차 출처 격리 상태가 되려면 Cross-Origin-Opener-Policy: same-origin과 Cross-Origin-Embedder-Policy: require-corp 또는 credentialless가 함께 필요하다고 설명한다. 또한 Permissions-Policy: cross-origin-isolated가 이를 막지 않아야 한다.
WHATWG HTML Standard는 COOP 값 자체로는 same-origin-plus-COEP를 직접 헤더에 쓰는 것이 아니라, same-origin과 교차 출처 격리에 호환되는 COEP 조합이 있을 때 내부적으로 그 상태가 성립한다고 설명한다. 따라서 COOP만 단독으로 설정해서는 SharedArrayBuffer 같은 기능 조건이 충족되지 않는다.
window.opener만 끊고 싶다면 rel=noopener로 충분할까?
일부 링크에는 rel=noopener만으로도 충분할 수 있다. 하지만 MDN은 COOP가 Window.open()으로 열린 문서까지 포함해 문서 간 관계를 더 넓게 제어할 수 있다고 설명한다. 즉 개별 링크 수준 제어와 문서 전체 정책 제어는 범위가 다르다.
도입 전에 확인할 점
- 팝업 로그인, 결제, 외부 콘솔처럼
window.opener또는 창 참조를 유지해야 하는 흐름이 있는지 확인해야 한다. - 교차 출처 격리가 목적이라면 COOP만이 아니라 COEP와
Permissions-Policy: cross-origin-isolated까지 함께 점검해야 한다. - 같은 origin 안의 여러 앱을 분리하려면 COOP 외에도 Fetch Metadata, 쿠키 속성, Service Worker 범위 같은 보완 통제가 필요하다.
- 링크 한두 개만 분리하면 되는지, 문서 전체 opener 정책이 필요한지 구분해야 한다.
FAQ
Q. COOP를 설정하면 CORS 없이도 교차 출처 데이터를 읽을 수 있나?
아니다. COOP는 문서 간 브라우징 컨텍스트와 opener 관계를 제어하는 헤더다. 네트워크 응답 읽기 허용은 여전히 CORS 같은 메커니즘이 담당한다.
Q. SharedArrayBuffer를 쓰려면 COOP만 넣으면 되나?
부족하다. MDN은 Cross-Origin-Opener-Policy: same-origin과 Cross-Origin-Embedder-Policy: require-corp 또는 credentialless가 함께 필요하고, Permissions-Policy: cross-origin-isolated가 이를 막지 않아야 한다고 설명한다.
Q. noopener-allow-popups를 쓰면 같은 origin 앱도 완전히 안전하게 분리되나?
그렇게 단정하면 과하다. MDN은 이 값만으로 충분한 보안 경계가 생기지는 않으며, 서버 측 요청 통제와 쿠키, Service Worker, 메시징 채널까지 함께 봐야 한다고 설명한다.
정리
COOP는 교차 출처 읽기 권한 헤더가 아니라, 새 문서와 현재 문서가 같은 browsing context group을 공유할지와 opener 관계를 유지할지를 정하는 정책이다. 2026년 6월 3일 기준 공식 문서상 실무 기본값은 단순하다. 강한 격리가 필요하면 same-origin, 신뢰한 외부 팝업 참조가 필요하면 same-origin-allow-popups, 같은 origin 내부에서도 opener 관계를 끊고 싶다면 noopener-allow-popups를 검토한다.
교차 출처 격리가 목표라면 COOP만 보면 부족하다. COEP와 cross-origin-isolated 권한까지 함께 확인해야 실제 기능 조건과 운영 호환성을 동시에 맞출 수 있다.
참고 자료
'프로그래밍 > HTML, Javascript, CSS' 카테고리의 다른 글
| Strict-Transport-Security 설정 기준 정리 (0) | 2026.06.12 |
|---|---|
| Cross-Origin-Embedder-Policy 기준 정리 (0) | 2026.06.06 |
| Cross-Origin-Resource-Policy 기준 정리 (1) | 2026.05.30 |
| X-Content-Type-Options nosniff 기준 정리 (0) | 2026.05.27 |
| Permissions-Policy 설정 기준 정리 (0) | 2026.05.20 |





