Cross-Origin-Resource-Policy 기준 정리

Cross-Origin-Resource-Policy 기준 정리

Cross-Origin-Resource-Policy(CORP)는 브라우저가 no-cors 방식으로 가져오는 교차 출처 리소스에 대해, 응답 소유자가 허용 범위를 직접 선언하게 하는 HTTP 응답 헤더다. 2026년 5월 30일 기준 MDN과 Fetch Standard를 보면 값은 same-origin, same-site, cross-origin 세 가지이며, 주로 이미지, 스크립트, 스타일시트 같은 임베드 리소스의 노출 범위를 좁히는 데 사용한다.

실무에서는 CORP를 CORS의 대체재로 보면 판단이 어긋나기 쉽다. CORP는 읽기 권한을 부여하는 헤더가 아니라, 원치 않는 no-cors 임베딩과 응답 노출을 제한하는 쪽에 가깝다. 이 글은 공식 문서 기준으로 CORP가 정확히 무엇을 막는지와 어떤 값이 무난한 선택인지 정리한다.

Cross-Origin-Resource-Policy는 무엇을 할까?

MDN은 CORP를 브라우저가 교차 출처 또는 교차 사이트의 no-cors 요청을 차단하도록 지시하는 응답 헤더로 설명한다. 여기서 핵심은 "요청 자체를 전송하지 않게 만드는 것"이 아니라 "브라우저가 해당 응답을 다른 출처 문서에 노출하지 않도록 제한하는 것"이다.

MDN의 구현 가이드는 실제 요청은 전송될 수 있지만, 브라우저가 응답 본문을 제거해 데이터 누출을 막는 방향으로 동작한다고 설명한다. 따라서 CORP는 트래픽 차단 장치라기보다 브라우저 측 노출 통제 장치로 이해하는 편이 정확하다.

CORS와는 무엇이 다를까?

CORS는 fetch()나 XMLHttpRequest 같은 교차 출처 읽기를 명시적으로 허용하는 메커니즘이다. 반면 CORP는 주로 img, script, link처럼 기본적으로 no-cors로 로드될 수 있는 리소스에 대해, 응답 제공자가 어디까지 임베딩을 허용할지 제한하는 데 초점이 있다.

즉 외부 프런트엔드가 API 응답 본문을 읽게 하려면 여전히 CORS가 필요하다. 반대로 사용자별 이미지, 내부 JSON, 사설 리소스가 다른 사이트에 임베드되는 범위를 줄이고 싶다면 CORP가 더 직접적인 수단이다.

값은 어떻게 고를까?

1. same-origin

MDN은 이 값을 민감한 사용자 정보나 비공개 API 응답에 권장한다. 요청을 보낸 문서의 origin이 응답 URL의 origin과 같을 때만 허용하므로 가장 보수적인 선택이다.

2. same-site

MDN은 여러 서브도메인이 기능을 나눠 쓰는 환경, 예를 들어 같은 회사의 CDN이나 SSO 애플리케이션처럼 같은 사이트 범위에서 공유해야 하는 리소스에 이 값을 권장한다. 다만 Fetch Standard는 단순히 등록 가능 도메인이 같다고 항상 허용되는 것은 아니라고 설명한다. 예를 들어 보안 전송으로 제공된 응답이 비보안 요청 문서와 만나는 경우는 same-site로 보지 않는다.

3. cross-origin

이 값은 어떤 origin에서도 리소스를 로드할 수 있게 한다. MDN 구현 가이드는 공개 CDN이나 외부 위젯처럼 넓게 배포해야 하는 리소스에만 이 값을 권장하며, 헤더를 아예 보내지 않을 때의 기본 동작도 사실상 이 방향이라고 설명한다.

언제 적용 효과가 분명할까?

민감한 파일 응답을 같은 브라우저에만 묶고 싶을 때

사용자별 프로필 이미지, 사내 전용 정적 리소스, 인증 이후에만 보여야 하는 다운로드 응답처럼 제3자 사이트에서 임베드될 이유가 없는 경우에는 same-origin이 기본 후보가 된다.

여러 서브도메인이 하나의 서비스처럼 동작할 때

static.example.com과 app.example.com처럼 같은 사이트 내부에서만 자산을 공유한다면 same-site가 현실적인 절충안이 될 수 있다. 이 경우 CORS처럼 허용 origin 목록을 세세하게 열기보다, 브라우저에 같은 사이트 범위까지만 허용하라고 선언하는 셈이다.

공개 배포 자산을 운영할 때

여러 외부 사이트가 공용으로 쓰는 라이브러리, 폰트, 위젯이라면 cross-origin이 필요할 수 있다. 다만 이 값은 보호 범위를 사실상 열어 두는 선택이므로, 정말 공개 배포가 목적일 때만 쓰는 편이 안전하다.

COEP와는 어떤 관계일까?

MDN의 Cross-Origin-Embedder-Policy(COEP) 문서는, 문서가 require-corp를 사용하면 교차 출처의 no-cors 리소스가 적절한 CORP 헤더를 보내거나 CORS로 허용되지 않는 한 로드되지 않는다고 설명한다. 즉 COEP는 문서 쪽의 요구사항이고, CORP는 리소스 쪽의 허용 선언이다.

따라서 SharedArrayBuffer 같은 교차 출처 격리가 필요한 기능을 준비하는 과정에서는 COEP만 켜서는 부족할 수 있다. 함께 불러오는 이미지, 스크립트, 워커, 폰트가 어떤 CORP 또는 CORS 정책을 보내는지까지 같이 확인해야 한다.

실무 점검 기준

• 외부 사이트가 실제로 임베드해야 하는 리소스인지 먼저 구분해야 한다.
• 민감하거나 로그인 문맥에 묶인 응답은 same-origin부터 검토하는 편이 안전하다.
• 서브도메인 간 공유가 필요할 때만 same-site를 검토하고, HTTP와 HTTPS가 섞여 있지 않은지도 봐야 한다.
• 공개 CDN, 위젯, 범용 자산이 아니라면 cross-origin은 기본값으로 두지 않는 편이 낫다.
• API 본문 읽기 허용이 목적이라면 CORP가 아니라 CORS 설정을 검토해야 한다.
• COEP를 도입하는 페이지라면 서드파티 자산의 CORP 또는 CORS 지원 여부를 함께 확인해야 한다.

FAQ

Q. CORP를 설정하면 교차 출처 요청이 아예 나가지 않나?

그렇게 이해하면 부정확하다. MDN 구현 가이드는 CORP가 실제 요청 자체를 막는 것이 아니라, 브라우저가 응답 본문을 노출하지 않도록 제한한다고 설명한다.

Q. API 서버에도 CORP만 넣으면 되나?

교차 출처 프런트엔드가 응답 본문을 읽어야 한다면 CORP만으로는 충분하지 않다. 그 경우에는 CORS 응답 헤더가 필요하다.

Q. same-site는 서브도메인이 같으면 항상 안전한가?

항상 그렇지는 않다. Fetch Standard는 same-site 판정에서 보안 전송 여부도 고려하며, HTTPS 응답이 HTTP 문서와 단순히 같은 registrable domain이라는 이유만으로 허용되는 구조가 아니다.

정리

CORP는 교차 출처 읽기 허용을 위한 헤더가 아니라, no-cors 리소스의 노출 범위를 리소스 소유자가 제한하는 헤더다. 2026년 5월 30일 기준 공식 문서상 기본 판단은 단순하다. 외부 임베드가 필요 없으면 same-origin, 같은 사이트 내부 공유만 필요하면 same-site, 공개 배포 자산일 때만 cross-origin을 검토한다.

특히 COEP를 함께 쓰는 환경에서는 개별 리소스가 CORP 또는 CORS 요구를 충족하는지까지 연결해서 봐야 운영 중 차단을 줄일 수 있다.

참고 자료

• MDN: Cross-Origin-Resource-Policy header
• MDN: Cross-Origin Resource Policy (CORP) implementation
• MDN: Cross-Origin-Embedder-Policy header
• WHATWG: Fetch Standard