교차 출처 리소스 공유

교차 출처 리소스 공유(Cross-origin resource sharing, CORS), 교차 출처 자원 공유는 웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다.^[1] 웹페이지는 교차 출처 이미지, 스타일시트, 스크립트, iframe, 동영상을 자유로이 임베드할 수 있다.^[2]

다만 특정 교차 도메인 간(cross-domain) 요청, 특히 Ajax 요청은 동일-출처 보안 정책에 의해 기본적으로 금지된다.

CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의한다.^[3] 순수하게 동일한 출처 요청보다 더 많은 자유와 기능을 허용하지만 단순히 모든 교차 출처 요청을 허용하는 것보다 더 안전하다. CORS의 사양은 원래 W3C 권고안으로 배포되었으나^[4] 해당 문서는 쓸모 없어진(obsolete) 상태이다.^[5] 현재 CORS를 재정의하면서 활발히 유지보수된 사양은 WHATWG의 Fetch Living Standard이다.^[6]

CORS의 동작 원리

다른 도메인을 가리키거나 허용 목록에 포함되지 않은 헤더를 포함하는 <form> 태그를 사용하여 수행할 수 없는 자바스크립트에서 생성된 HTTP 요청의 경우 사양에서는 브라우저가 요청을 "사전 실행"(preflight)하여 HTTP를 사용하여 서버에서 지원되는 메서드를 요청하도록 규정한다. OPTIONS 요청 메소드를 사용하고 서버에서 "승인"되면 실제 HTTP 요청 메소드로 실제 요청을 보낸다. 또한 서버는 요청과 함께 "자격 증명"(쿠키 및 HTTP 인증 데이터 포함)을 보내야 하는지 여부를 클라이언트에게 알릴 수 있다.^[7]

헤더

CORS 관련 HTTP 헤더는 다음과 같다:

요청 헤더

Origin
Access-Control-Request-Method
Access-Control-Request-Headers

응답 헤더

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers

지원 브라우저

Blink 및 Chromium 기반 브라우저(Chrome 28+, Opera 15+, Amazon Silk, Android의 4.4+ WebView 및 Qt의 WebEngine)
Gecko 1.9.1(Firefox 3.5, SeaMonkey 2.0) 이상.
MSHTML/Trident 6.0(Internet Explorer 10)은 기본적으로 지원된다. MSHTML/Trident 4.0 및 5.0(Internet Explorer 8 및 9)은 XDomainRequest 개체를 통해 부분적인 지원을 제공한다.
Presto 기반 브라우저(Opera)는 Opera 12.00 및 Opera Mobile 12부터 CORS를 구현하지만 Opera Mini는 구현하지 않는다.
WebKit(초기 버전은 불확실함, Safari 4 이상, Google Chrome 3 이상, 이전 버전일 수도 있음)
Microsoft Edge 모든 버전.

역사

교차 출처 지원(Cross-origin support)은 원래 VoiceXML 브라우저의 안전한 교차 출처 데이터 요청을 허용하기 위해 VoiceXML 2.1에 포함시키기 위해 텔미 네트웍스(Tellme Networks)의 맷 오시리, 브래드 포터, 마이클 보델에 의해 제안되었다. 이 메커니즘은 본질적으로 일반적인 것으로 간주되어 VoiceXML에만 국한되지 않으며 이후에 구현 참고로 분리되었다. 주요 브라우저 공급업체가 참여한 W3C의 웹앱스(WebApps) 워킹 그룹은 공식적인 W3C 권장 사항 상태를 향한 궤도에 있는 W3C 작업 초안으로 NOTE를 공식화하기 시작했다.

2006년 5월에 첫 번째 W3C 작업 초안이 제출되었다. 2009년 3월 초안은 "Cross-Origin Resource Sharing"으로 이름이 바뀌었고 2014년 1월 W3C 권장 사항으로 승인되었다.

CORS vs JSONP

CORS는 JSONP 패턴에 대한 현대적인 대안으로 사용될 수 있다. CORS의 이점은 다음과 같다.

JSONP는 GET 요청 방식만 지원하지만 CORS는 다른 유형의 HTTP 요청도 지원한다.
CORS를 사용하면 웹 프로그래머가 JSONP보다 더 나은 오류 처리를 지원하는 일반 XMLHttpRequest를 사용할 수 있다.
JSONP는 외부 사이트가 손상될 때 XSS(교차 사이트 스크립팅) 문제를 일으킬 수 있지만 CORS는 웹사이트에서 응답을 수동으로 구문 분석하여 보안을 강화할 수 있도록 한다.

JSONP의 가장 큰 장점은 CORS 지원 이전의 레거시 브라우저(Opera Mini 및 Internet Explorer 9 이하)에서 작동할 수 있다는 것이다. CORS는 이제 대부분의 최신 웹 브라우저에서 지원된다.

같이 보기

콘텐츠 보안 정책

각주

↑ on July 6, 2009 by Arun Ranganathan (2009년 7월 6일). “cross-site xmlhttprequest with CORS ✩ Mozilla Hacks – the Web developer blog”. Hacks.mozilla.org. 2012년 7월 5일에 확인함.
↑ “Same-origin policy / Cross-origin network access”. MDN.
↑ “Cross-domain Ajax with Cross-Origin Resource Sharing”. NCZOnline. 2012년 7월 5일에 확인함.
↑ “Cross-Origin Resource Sharing”.
↑ “WebAppSec Working Group Minutes”.
↑ “Fetch Living Standard”.
↑ “Cross-Origin Resource Sharing (CORS) - HTTP | MDN”. 《developer.mozilla.org》. 2023년 5월 10일. 2023년 6월 7일에 확인함.

외부 링크

Fetch Living Standard (the current specification for CORS)

이 글은 웹사이트에 관한 토막글입니다. 여러분의 지식으로 알차게 문서를 완성해 갑시다.

[mozhacks_cors-1] July 6, 2009 by Arun Ranganathan (2009년 7월 6일). “cross-site xmlhttprequest with CORS ✩ Mozilla Hacks – the Web developer blog”. Hacks.mozilla.org. 2012년 7월 5일에 확인함.

[2] “Same-origin policy / Cross-origin network access”. MDN.

[nczonline1-3] “Cross-domain Ajax with Cross-Origin Resource Sharing”. NCZOnline. 2012년 7월 5일에 확인함.

[4] “Cross-Origin Resource Sharing”.

[5] “WebAppSec Working Group Minutes”.

[6] “Fetch Living Standard”.

[mdncors-7] “Cross-Origin Resource Sharing (CORS) - HTTP | MDN”. 《developer.mozilla.org》. 2023년 5월 10일. 2023년 6월 7일에 확인함.

[1]

[2]

[3]

[4]

[5]

[6]

[7]