🛡️ Cross-Origin Isolation

들어가며

최근 웹 프론트엔드 보안 관련 책을 읽던 중 Cross-Origin Isolation이라는 개념을 접하게 되었습니다.

책에서는 간단히 언급만 되어 있어서, 더 자세히 알아보고 싶어서 추가로 찾아본 내용들을 정리해보았습니다. 특히 이 기술이 어떻게 발전해왔는지, 그 배경을 살펴보면서 이해해보겠습니다.

🚨 2018년, 웹 보안의 전환점: Spectre 취약점 발견

Spectre 취약점이란?

2018년 1월 발견된 CPU 하드웨어 취약점입니다. CPU가 성능 향상을 위해 "미리 계산해두는" 기능을 악용하여, 다른 프로그램의 비밀 정보를 훔칠 수 있습니다.

비유: 은행 직원이 다음 고객 서류를 미리 준비했다가, 실제로는 그 고객이 오지 않았지만 책상에 남은 서류 흔적을 보고 다른 고객의 개인정보를 추측하는 것과 같습니다.

SharedArrayBuffer의 급작스러운 비활성화

Spectre 발견과 동시에 모든 주요 브라우저에서 SharedArrayBuffer가 긴급 비활성화되었습니다.

왜 SharedArrayBuffer가 문제였을까?

SharedArrayBuffer 자체는 나쁜 기술이 아니었습니다. 하지만 Spectre 공격을 더 정확하게 만드는 정밀한 시계 역할을 할 수 있었기 때문입니다.

비유로 설명하면:

Spectre 공격 = 자물쇠를 따는 것
SharedArrayBuffer = 매우 정확한 스톱워치

자물쇠를 딸 때 "똑" 소리가 나는 타이밍을 
정확히 측정할 수 있다면 비밀번호를 알아낼 확률이 높아집니다.

SharedArrayBuffer가 바로 그 "정확한 스톱워치" 역할을 했습니다.

따라서 SharedArrayBuffer는 그 자체로는 문제가 없었지만, Spectre 공격의 정확도를 크게 높여주는 도구였기 때문에 비활성화될 수밖에 없었습니다.

기존 브라우저 아키텍처의 위험성

2018년 당시 브라우저는 모든 사이트(구글, 페이스북, 은행, 악성 사이트)가 하나의 프로세스에서 돌아갔습니다.

같은 메모리 공간을 공유했기 때문에 악성 사이트가 Spectre 공격으로 다른 사이트의 민감한 데이터에 접근할 수 있었습니다.

마치 4명이 같은 방에서 일하다가 해커가 다른 사람의 작업 내용을 엿보는 것과 같았습니다.

🏗️ 첫 번째 해결책: Site Isolation

Site Isolation의 등장

Spectre 위협에 대응하기 위해 브라우저들은 Site Isolation을 강화하기 시작했습니다. Chrome이 선두를 달렸고, 다른 브라우저들도 뒤따랐습니다.

새로운 프로세스 분리 구조:

프로세스 A: google.com
프로세스 B: facebook.com  
프로세스 C: bank.com
프로세스 D: malicious-site.com
→ 운영체제가 프로세스 간 메모리 접근을 차단

eTLD+1 기준의 사이트 구분

브라우저는 eTLD+1(effective Top-Level Domain + 1) 기준으로 "사이트"를 정의합니다:

// 같은 사이트로 분류되는 예시들
'www.example.com'    → 사이트: example.com
'api.example.com'    → 사이트: example.com (같은 프로세스)
'cdn.example.com'    → 사이트: example.com (같은 프로세스)

// 다른 사이트로 분류되는 예시들  
'alice.github.io'    → 사이트: alice.github.io
'bob.github.io'      → 사이트: bob.github.io (다른 프로세스)

// 한국 도메인 예시
'blog.naver.co.kr'   → 사이트: naver.co.kr
'mail.naver.co.kr'   → 사이트: naver.co.kr (같은 프로세스)
'blog.daum.co.kr'    → 사이트: daum.co.kr (다른 프로세스)

Site Isolation의 한계

example.com 프로세스 (단일 프로세스)
├── evil.example.com (악성 서브도메인)
└── banking.example.com (중요한 금융 서비스)
→ 같은 사이트로 분류

실제 서비스에서는 서브도메인을 다양한 용도로 사용하는데, 서브도메인은 같은 사이트로 분류되어 Spectre 공격 가능하다는 문제가 있습니다.

🛡️ 두 번째 해결책: Cross-Origin Isolation

Site Isolation만으로는 같은 사이트 내의 다른 출처 간 공격을 막을 수 없다는 것이 명확해졌습니다.
이에 대한 해결책으로 Cross-Origin Isolation이 있습니다.

Cross-Origin Isolation의 구현

Cross-Origin Isolation은 세 가지 HTTP 헤더로 출처 단위 격리를 구현합니다.

1. CORP (Cross-Origin-Resource-Policy): 리소스 보호

역할: 개별 파일(이미지, API, 스크립트 등)이 어떤 사이트에서 사용될 수 있는지 제한

Cross-Origin-Resource-Policy: same-origin     # 같은 출처만 OK
Cross-Origin-Resource-Policy: same-site       # 같은 사이트만 OK  
Cross-Origin-Resource-Policy: cross-origin    # 모든 사이트 OK

2. COEP (Cross-Origin-Embedder-Policy): 페이지 보호

역할: 내 페이지가 로드하는 모든 외부 리소스에 대해 "허가증"(CORP 헤더) 확인을 강제

Cross-Origin-Embedder-Policy: require-corp

동작 방식:

<!-- COEP 설정하면 이런 것들이 차단됨 -->
<img src="https://다른사이트.com/image.jpg">  ❌ CORP 헤더 없음
<script src="https://cdn.com/library.js">    ❌ CORP 헤더 없음

<!-- 이런 것들만 허용됨 -->
<img src="https://허가된사이트.com/image.jpg">  ✅ CORP 헤더 있음
<img src="/내사이트/image.jpg">              ✅ 같은 출처

3. COOP (Cross-Origin-Opener-Policy): 윈도우 보호

역할: 내 페이지가 열어준 다른 사이트 창(팝업)과의 연결을 차단

Cross-Origin-Opener-Policy: same-origin

a 태그나 window.open()으로 열린 교차 출처 페이지는 원래 오픈한 페이지와 같은 프로세스에서 동작합니다.

이때 window.opener로 교차 출처 페이지에 접근이 가능해서 보안 위험이 있습니다.COOP를 활용하면, 이러한 교차 출처 페이지의 접근을 제한할 수 있습니다.

세 헤더의 협력

이 세 헤더가 함께 작동하면 완전한 출처 격리가 완성됩니다:

CORP: "이 파일은 누가 쓸 수 있나?"
COEP: "내 페이지는 허가된 파일만 쓸 거야"  
COOP: "내 페이지는 다른 사이트 창과 단절할 거야"

→ 결과: 완전히 격리된 안전한 환경

🆕 세 번째 진화: Document Isolation Policy

기존 방식의 현실적 문제들

Cross-Origin Isolation이 이론적으로는 완벽했지만, 현실에서는 여러 문제가 있었습니다:

1. 광고 스크립트 문제

• 대부분의 광고 네트워크가 CORP 헤더를 지원하지 않습니다.

2. OAuth/결제 시스템 문제

• OAuth/결제 시스템은 보통 다른 사이트(구글, 페이팔 등)를 팝업으로 열어서 인증을 처리한 후, 그 결과를 원래 사이트로 전달하는 방식으로 동작합니다.

• Cross-Origin Isolation의 COOP 헤더를 적용하면 보안을 위해 다른 출처의 윈도우와의 연결을 강제로 차단하기 때문에, 팝업 참조가 null이 되어 통신이 불가능해집니다.

3. 복잡한 설정

• 모든 서브리소스에 대해 CORP 헤더 확인 필요합니다.

Document Isolation Policy의 등장

Chrome 137 (2025)부터 지원:

# 기존 복잡한 방식
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

# 새로운 단순한 방식
Document-Isolation-Policy: isolate-and-require-corp

특징:

• 프레임별 개별 적용 가능
• 하위 프레임에 제약 없음
• 크로스 오리진 팝업과 통신 유지
• OAuth/결제 시스템과 호환

마무리

흥미로웠던 점은 웹 보안이 결국 "누구와 누구를 같은 공간에 둘 것인가?"의 문제라는 것이었습니다. 같은 프로세스에 있으면 서로 공격할 수 있고, 다른 프로세스에 있으면 운영체제가 막아준다는 단순한 원리가 이렇게 복잡한 보안 정책의 근간이 되는 것이 재미있었습니다

---

참고 자료

• 프런트엔드 개발을 위한 보안 입문