HTTP/Guides/Cross-Origin Resource Policy (CORP)

김동현·2026년 3월 22일

mdn 학습 번역 - Web Technology

목록 보기

25/28

안녕하세요! 프론트엔드 개발자 여러분, 보안의 세계로 한 걸음 더 깊이 들어갈 준비가 되셨나요? 🛡️

오늘은 브라우저의 보안 메커니즘 중에서도 비교적 최신 기술이자, 복잡한 하드웨어 취약점을 방어하기 위해 꼭 알아두어야 할 교차 출처 리소스 정책 (Cross-Origin Resource Policy, CORP)에 대해 배워보겠습니다.

단순히 SOP(동일 출처 정책)나 CORS를 아는 것을 넘어서, 이 CORP가 왜 등장했는지, 그리고 어떻게 우리의 소중한 데이터를 지켜내는지 강사의 팁과 함께 구어체로 알기 쉽게, 원문 그대로 상세히 설명해 드릴게요. 자, 시작해 볼까요?

교차 출처 리소스 정책 (Cross-Origin Resource Policy, CORP)

교차 출처 리소스 정책(Cross-Origin Resource Policy)은 >Cross-Origin-Resource-Policy HTTP 헤더를 통해 설정하는 보안 정책입니다. 웹사이트와 애플리케이션이 다른 출처에서 오는 특정 요청(예: <script>나 <img> 요소 등으로 발생하는 요청)으로부터 스스로를 보호할 수 있도록 선택적(opt in)으로 적용할 수 있습니다. 이를 통해 Spectre와 같은 추측성 부채널 공격(speculative side-channel attacks)은 물론, XSSI(Cross-Site Script Inclusion) 공격도 완화할 수 있습니다.
CORP는 브라우저의 기본 동일 출처 정책(same-origin policy)을 넘어서는 추가적인 방어 계층입니다.

참고 (Note):
이 정책은 CORS 안전 목록(safelisted)에 있는 메서드/헤더에 대해 기본적으로 발행되는 no-cors 요청 모드에만 유효합니다.

이 정책은 응답 헤더(response header)를 통해 표현되기 때문에, 실제 요청이 서버로 가는 것 자체를 막지는 못합니다. 그 대신 브라우저가 응답의 본문(body)을 비워버림으로써 그 결과물이 유출되는 것을 차단합니다.

💡 강사의 부연 설명!
쉽게 말해서 공격자가 악의적인 사이트에서 우리 사이트의 이미지나 스크립트를 몰래 불러와서 안에 있는 데이터를 빼내려고 할 때, "어딜 감히! 너희 출처엔 응답 내용 안 보여줄 거야!" 하고 브라우저가 빈 껍데기만 던져주게 만드는 든든한 자물쇠랍니다.

사용법 (Usage)

주의 (Note):
Chrome 브라우저의 버그로 인해, Cross-Origin-Resource-Policy를 설정하면 PDF 렌더링이 깨져서 방문자가 PDF의 첫 페이지 이후로는 읽지 못하게 되는 문제가 발생할 수 있습니다. 프로덕션(실제 서비스) 환경에서 이 헤더를 사용할 때는 매우 주의하셔야 합니다.

웹 애플리케이션은 Cross-Origin-Resource-Policy HTTP 응답 헤더를 통해 교차 출처 리소스 정책을 설정하며, 다음 세 가지 값 중 하나를 허용합니다:

same-site
동일한 사이트(Site)에서 온 요청만 해당 리소스를 읽을 수 있습니다.

경고 (Warning):
이 설정은 출처(origin) 단위의 제한보다 덜 안전합니다. 두 출처가 같은 사이트인지 확인하는 알고리즘은 HTML 표준에 정의되어 있으며, 등록 가능한 도메인(registrable domain)을 확인하는 과정을 거칩니다.
same-origin
동일한 출처(origin) (즉, 스킴 + 호스트 + 포트가 모두 같은 곳)에서 온 요청만 해당 리소스를 읽을 수 있습니다.
cross-origin
동일 사이트든 교차 사이트든 관계없이, 어떤 출처(origin)에서 온 요청이라도 리소스를 읽을 수 있습니다. 이 값은 COEP를 사용할 때 매우 유용합니다 (아래에서 설명할게요).

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

교차 출처 리소스 정책을 검사하는 동안, 이 헤더가 설정되어 있다면 브라우저는 다른 출처나 사이트에서 발행된 no-cors 요청을 거부(deny)하게 됩니다.

교차 출처 임베더 정책 (COEP)과의 관계 (Relationship to cross-origin embedder policy (COEP))

어떤 문서에 Cross-Origin-Embedder-Policy HTTP 응답 헤더가 사용될 경우, 이 문서는 자신에게 포함되는 하위 리소스(subresources)들이 해당 문서와 동일한 출처(same-origin)이거나, 혹은 임베드되어도 괜찮다는 것을 알리는 Cross-Origin-Resource-Policy 응답 헤더를 달고 오도록 강제할 수 있습니다.
바로 이 목적 때문에 cross-origin 이라는 값이 존재하는 것입니다!

💡 강사의 실무 TIP!
"도대체 내 사이트 리소스를 아무나 다 가져가게 냅두는 cross-origin 값이 왜 필요한 거죠?" 라고 생각하실 수 있어요.
최근 웹에서 SharedArrayBuffer 같은 강력한 기능을 안전하게 쓰려면 웹 페이지를 교차 출처 격리(Cross-Origin Isolation) 상태로 만들어야 하는데요. 이를 위해 COEP: require-corp를 설정해야 합니다. 이때 다른 서버(예: 외부 CDN 이미지 서버)에 있는 리소스를 우리 페이지로 정상적으로 불러오기 위해서는, 그 외부 서버 쪽에서 "이 리소스는 다른 사이트(교차 출처)에 삽입되어도 안전해!"라고 허락해주는 징표가 필요해요. 그 징표가 바로 Cross-Origin-Resource-Policy: cross-origin이랍니다!

역사 (History)

이 개념은 2012년에 원래 From-Origin 헤더라는 이름으로 처음 제안되었지만 잊혀졌다가, 2018년 2분기에 다시 부활하여 Safari와 Chromium 브라우저에 구현되었습니다.

2018년 초, Meltdown(멜트다운)과 Spectre(스펙터)로 알려진 두 가지 하드웨어 부채널 취약점이 세상에 공개되었습니다. 이 취약점들은 성능 향상을 위해 설계된 '추측성 실행(speculative execution)' 기능에서 발생하는 레이스 컨디션(race condition)을 이용해, 메모리 속 민감한 데이터를 외부로 노출시킬 수 있게 만들었습니다.

교차 출처 리소스 정책(CORP)은 사이트들이 원치 않는 교차 출처의 no-cors 요청을 차단할 수 있는 아주 직접적인 방법으로 개발되었습니다. 공격자가 응답 결과에 접근하기도 전에 브라우저가 먼저 응답의 본문을 싹 지워버리기 때문에, Spectre와 같은 공격을 효과적으로 방어할 수 있습니다.

명세 (Specifications)

명세 (Specification)
Fetch # cross-origin-resource-policy-header

브라우저 호환성 (Browser compatibility)

각 브라우저 환경에서 이 기능이 언제부터 지원되기 시작했는지 나타내는 표입니다. (최신 브라우저들은 대부분 잘 지원하고 있습니다!)

브라우저 (Browser)	지원 버전
Chrome (데스크톱)	73 버전부터 지원
Edge (데스크톱)	79 버전부터 지원
Firefox (데스크톱)	74 버전부터 지원
Opera (데스크톱)	60 버전부터 지원
Safari (데스크톱)	12 버전부터 지원
Chrome Android	73 버전부터 지원
Firefox for Android	79 버전부터 지원
Opera Android	52 버전부터 지원
Safari on iOS	12 버전부터 지원
Samsung Internet	11 버전부터 지원
WebView Android	73 버전부터 지원
WebView on iOS	12 버전부터 지원