교차 출처 리소스 공유
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
교차 출처 리소스 공유(CORS)는 웹 페이지가 다른 도메인의 리소스에 접근하도록 허용하는 보안 메커니즘이다. 2004년에 처음 제안되었으며, HTTP 헤더를 사용하여 브라우저와 서버 간의 통신을 제어한다. CORS는 단순 요청과 사전 요청 두 가지 방식으로 동작하며, `Origin` 헤더와 `Access-Control-Allow-Origin` 등의 응답 헤더를 사용하여 교차 출처 요청을 허용하거나 거부한다. CORS는 JSONP에 대한 현대적인 대안으로, 다양한 HTTP 요청 방식 지원, 향상된 오류 처리, XSS 공격 방어 등의 장점을 제공하며, 현재 대부분의 최신 웹 브라우저에서 지원된다.
더 읽어볼만한 페이지
- Ajax - 구글 문서도구
구글 문서도구는 구글에서 제공하는 웹 기반 워드 프로세서로, 문서 작성, 편집, 공유 기능을 제공하며, 다양한 문서 형식 지원, 실시간 공동 작업, 머신러닝 기반 기능을 제공하고, 구글 드라이브를 통해 문서 및 파일을 함께 이용할 수 있다. - Ajax - AngularJS
AngularJS는 동적 웹 애플리케이션 개발을 용이하게 하기 위해 설계된 오픈 소스 자바스크립트 프레임워크로, MVC 패턴 적용, 의존성 주입, HTML 확장 디렉티브 제공, 양방향 데이터 바인딩 등의 특징을 가지며, 장기 지원은 종료되었지만 웹 개발에 중요한 영향을 미쳤다. - W3C 표준 - HTML
HTML은 웹 페이지 제작을 위한 표준 마크업 언어로서, 팀 버너스리가 제안하고 구현한 후 인터넷 발전과 함께 널리 사용되며, SGML에 기반하여 하이퍼텍스트 기능으로 다양한 콘텐츠를 표현하고 연결하며, W3C와 WHATWG에서 표준화를 진행하고 최신 버전은 HTML Living Standard이다. - W3C 표준 - 타임드 텍스트
타임드 텍스트는 영상이나 오디오 콘텐츠에 시간 정보를 담아 표현되는 텍스트로, 자막이나 캡션 등에 활용되며 TTML, WebVTT 등의 표준이 존재한다.
| 교차 출처 리소스 공유 | |
|---|---|
| 개요 | |
| 이름 | 교차 출처 리소스 공유 |
| 영어 이름 | Cross-Origin Resource Sharing (CORS) |
| 약자 | CORS |
| 설명 | 웹 페이지가 다른 도메인의 리소스를 요청할 수 있게 하는 메커니즘 |
| 기술 상세 | |
| 주요 목적 | XMLHttpRequest 또는 Fetch API를 사용하는 웹 페이지가 다른 도메인에서 리소스를 요청할 수 있도록 허용 |
| 동작 방식 | 브라우저는 교차 출처 요청을 하기 전에 서버에 "프리플라이트" 요청을 보내 서버가 해당 출처를 신뢰하는지 확인 |
| HTTP 헤더 | 서버는 `Access-Control-Allow-Origin` 헤더를 사용하여 허용되는 출처를 지정 |
| 보안 고려 사항 | 올바르게 구성되지 않은 CORS 정책은 보안 취약점을 야기할 수 있음 |
| 관련 기술 | |
| 관련 기술 | XMLHttpRequest Fetch API Same-Origin Policy |
| 표준화 | |
| 표준 | W3C 권고안으로 정의됨 |
2. 역사
VoiceXML 브라우저에서 안전한 교차 출처 데이터 요청을 허용하기 위해 2004년 3월 Tellme Networks의 맷 오시리, 브래드 포터, 마이클 보델이 VoiceXML 2.1에 포함시키기 위해 교차 출처 지원을 처음 제안했다.[19] 이 메커니즘은 일반적인 성격을 띠며 VoiceXML에 국한되지 않는 것으로 간주되어, 이후 구현 NOTE로 분리되었다.[20] 주요 브라우저 공급업체의 참여와 함께 W3C의 WebApps Working Group은 NOTE를 공식적인 W3C 작업 초안으로 공식화하기 시작하여 공식적인 W3C 권고안 지위를 갖추게 되었다.
CORS는 HTTP 헤더를 사용하여 브라우저와 서버 간의 교차 출처 요청 허용 여부를 결정한다. CORS는 단순 요청(Simple request)과 사전 요청(Preflight request) 두 가지 방식으로 동작한다.
2006년 5월 첫 번째 W3C 작업 초안이 제출되었다.[21] 2009년 3월 이 초안은 "교차 출처 리소스 공유"로 이름이 변경되었으며,[22] 2014년 1월 W3C 권고안으로 채택되었다.[23]
3. 동작 원리
어떤 경우든 서버는 요청과 함께 쿠키 및 HTTP 인증 데이터 등 "자격 증명"을 보낼지 여부를 클라이언트에 알릴 수 있다.[5]
3. 1. 단순 요청 (Simple request)
사용자가 `http://www.example.com`을 방문하고 해당 페이지가 `http://service.example.com`에서 데이터를 가져오기 위해 교차 출처 요청을 시도한다고 가정해 보자. CORS 호환 브라우저는 `service.example.com`에 다음과 같이 교차 출처 요청을 시도한다.
와일드카드 동일 출처 정책은 페이지 또는 API 응답이 모든 사이트의 모든 코드에서 액세스할 수 있도록 하려는 경우에 적합하다. 구글 폰트(Google Fonts)와 같은 공개 호스팅 서비스의 자유롭게 사용할 수 있는 웹 폰트가 그 예이다.
"*" 값은 자격 증명을 제공하는 요청을 허용하지 않는다는 점에서 특별하며, 이는 교차 도메인 요청에서 HTTP 인증, 클라이언트 측 SSL 인증서 또는 쿠키를 보낼 수 없음을 의미한다.[7]
CORS 아키텍처에서 `Access-Control-Allow-Origin` 헤더는 원래 웹 애플리케이션 서버(`www.example.com`)가 아닌 외부 웹 서비스 (`service.example.com`)에 의해 설정된다. 여기서 `service.example.com`은 CORS를 사용하여 브라우저가 `www.example.com`이 `service.example.com`에 요청을 할 수 있도록 권한을 부여한다.
사이트가 "Access-Control-Allow-Credentials:true" 헤더를 지정하면 타사 사이트에서 권한 있는 작업을 수행하고 민감한 정보를 검색할 수 있다.
3. 2. 사전 요청 (Preflight request)
단순 요청 조건에 해당하지 않는 HTTP 요청은 실제 요청을 보내기 전에 OPTIONS 메서드를 사용하여 사전 요청(Preflight request)을 보낸다.[31][5] 브라우저는 OPTIONS 요청을 통해 서버에 실제 요청을 보내도 안전한지 확인한다. 서버는 응답 헤더에 관련 정보를 포함하여 사전 요청에 응답하고, 브라우저는 서버의 응답을 확인하고 실제 요청 전송 여부를 결정한다.
예를 들어, 자바스크립트를 사용하여 다른 도메인에 요청하거나, 허용 목록에 없는 헤더를 포함하는 HTTP 요청을 생성하는 경우, 브라우저는 먼저 OPTIONS 요청을 보낸다. 서버가 요청을 허용하면 실제 요청을 보내고, 허용하지 않으면 오류로 응답하여 실제 요청을 보내지 않는다.[5]
다음은 사전 요청의 예시이다.
```
OPTIONS /
Host: service.example.com
Origin: http://www.example.com
Access-Control-Request-Method: PUT
```
`service.example.com`이 해당 작업을 허용하는 경우, 다음 헤더로 응답할 수 있다.
```
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: PUT
```
서버가 위와 같이 응답하면, 브라우저는 실제 요청을 전송한다. 서버가 이 출처로부터의 교차 사이트 요청을 허용하지 않으면, OPTIONS 요청에 오류로 응답하고 브라우저는 실제 요청을 보내지 않는다.
4. 관련 HTTP 헤더
CORS와 관련된 HTTP 헤더는 요청 헤더와 응답 헤더로 구분된다.
| 요청 헤더 (Request headers) | 응답 헤더 (Response headers) |
|---|---|
사용자가 `http://www.example.com`을 방문하고 해당 페이지가 `http://service.example.com`에서 데이터를 가져오기 위해 교차 출처 요청을 시도한다고 가정할 때, CORS를 지원하는 브라우저는 `Origin` HTTP 헤더를 추가하여 요청을 보낸다. 서버는 `Access-Control-Allow-Origin` 헤더를 포함한 응답을 통해 요청 허용 여부를 알린다.[6]
와일드카드(`*`)를 사용하면 모든 도메인의 요청을 허용할 수 있지만, 이 경우 HTTP 인증, 클라이언트 측 SSL 인증서, 쿠키와 같은 자격 증명은 보낼 수 없다.[7] Google Fonts와 같이 공개된 서비스에서 사용되는 웹 폰트가 이러한 예시이다.
CORS 아키텍처에서 `Access-Control-Allow-Origin` 헤더는 외부 웹 서비스 (`service.example.com`)에 의해 설정되어, 브라우저가 원래 웹 애플리케이션 서버(`www.example.com`)의 요청을 허용하도록 권한을 부여한다. 만약 사이트가 `Access-Control-Allow-Credentials:true` 헤더를 지정하면, 타사 사이트에서 권한 있는 작업을 수행하고 민감한 정보를 검색할 수 있게 된다.
특정 유형의 교차 도메인 Ajax 요청의 경우, 최신 브라우저는 실제 요청을 보내기 전 `OPTIONS` 메서드를 사용하여 "사전 요청"(Preflight)을 보내 서버의 허용 여부를 확인한다.
4. 1. 요청 헤더 (Request headers)
CORS 관련 요청 헤더에는 다음과 같은 것들이 있다.다른 도메인을 가리키거나 안전 목록에 없는 헤더를 포함하는 <form> 태그를 사용하여 만들 수 없는 자바스크립트에서 생성된 HTTP 요청의 경우, 브라우저는 HTTP `OPTIONS` 요청 메서드를 사용하여 서버로부터 지원되는 메서드를 요청하고, 서버의 "승인"을 받은 후 실제 HTTP 요청 메서드로 실제 요청을 보내도록 규정하고 있다.
특정 유형의 교차 도메인 Ajax 요청을 수행할 때, CORS를 지원하는 최신 브라우저는 해당 작업을 수행할 권한이 있는지 확인하기 위해 추가적인 "사전 요청"을 시작한다. 교차 출처 요청은 사용자 데이터에 영향을 미칠 수 있으므로 이런 방식으로 사전 요청을 거친다.[5]
```
OPTIONS /
Host: service.example.com
Origin: http://www.example.com
Access-Control-Request-Method: PUT
```
만약 service.example.com이 해당 작업을 허용하려는 경우, 다음 헤더로 응답할 수 있다.
```
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: PUT
```
그러면 브라우저는 실제 요청을 보낸다. 만약 service.example.com이 이 출처로부터의 교차 사이트 요청을 허용하지 않는다면, `OPTIONS` 요청에 오류로 응답하고 브라우저는 실제 요청을 보내지 않는다.
4. 2. 응답 헤더 (Response headers)
CORS와 관련된 응답 헤더는 다음과 같다.- `Access-Control-Allow-Origin`
- `Access-Control-Allow-Credentials`
- `Access-Control-Expose-Headers`
- `Access-Control-Max-Age`
- `Access-Control-Allow-Methods`
- `Access-Control-Allow-Headers`
사용자가 `http://www.example.com`을 방문하고 해당 페이지가 `http://service.example.com`에서 데이터를 가져오기 위해 교차 출처 요청을 시도한다고 가정해 보자. CORS 호환 브라우저는 `service.example.com`에 다음과 같이 교차 출처 요청을 시도한다.
1. 브라우저는 상위 페이지를 제공한 도메인을 포함하는 `Origin` HTTP 헤더를 추가하여 `service.example.com`에 GET 요청을 보낸다.
2. `service.example.com`의 서버는 다음 세 가지 응답 중 하나를 보낸다.
- 요청된 데이터와 함께 요청 출처가 허용됨을 나타내는 `Access-Control-Allow-Origin` (ACAO) 헤더를 포함하는 응답. 예를 들어 이 경우 다음과 같아야 한다.
- 요청된 데이터와 모든 도메인의 요청이 허용됨을 나타내는 와일드카드와 함께 `Access-Control-Allow-Origin` (ACAO) 헤더를 포함하는 응답.
- 서버가 교차 출처 요청을 허용하지 않는 경우 오류 페이지.[6]
와일드카드 동일 출처 정책은 페이지 또는 API 응답이 모든 사이트의 모든 코드에서 접근할 수 있도록 하려는 경우에 적합하다. 구글 폰트(Google Fonts)와 같은 공개 호스팅 서비스에서 자유롭게 사용할 수 있는 웹 폰트가 그 예이다.
`*` 값은 자격 증명을 제공하는 요청을 허용하지 않는다는 점에서 특별하며, 이는 교차 도메인 요청에서 HTTP 인증, 클라이언트 측 SSL 인증서 또는 쿠키를 보낼 수 없음을 의미한다.[7]
CORS 아키텍처에서 `Access-Control-Allow-Origin` 헤더는 원래 웹 애플리케이션 서버(`www.example.com`)가 아닌 외부 웹 서비스 (`service.example.com`)에 의해 설정된다. 여기서 `service.example.com`은 CORS를 사용하여 브라우저가 `www.example.com`이 `service.example.com`에 요청을 할 수 있도록 권한을 부여한다.
사이트가 `Access-Control-Allow-Credentials:true` 헤더를 지정하면 타사 사이트에서 권한 있는 작업을 수행하고 민감한 정보를 검색할 수 있다.
특정 유형의 교차 도메인 Ajax 요청을 수행할 때, CORS를 지원하는 최신 브라우저는 해당 작업을 수행할 권한이 있는지 확인하기 위해 추가적인 "사전 요청"을 시작한다. 교차 출처 요청은 사용자 데이터에 영향을 줄 수 있으므로 이런 방식으로 사전 요청을 거친다.
만약 `service.example.com`이 해당 작업을 허용하려는 경우, 다음 헤더로 응답할 수 있다.
```
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: PUT
```
그러면 브라우저는 실제 요청을 보낸다. 만약 `service.example.com`이 이 출처로부터의 교차 사이트 요청을 허용하지 않는다면, OPTIONS 요청에 오류로 응답하고 브라우저는 실제 요청을 보내지 않는다.
5. 브라우저 지원 현황
대부분의 최신 웹 브라우저는 CORS를 지원한다.[8] CORS는 다음과 같은 레이아웃 엔진을 기반으로 하는 모든 브라우저에서 지원된다.
- Blink 및 크로미움 기반 브라우저
- Gecko 1.9.1 이상
- MSHTML/Trident 6.0 (기본 지원), 4.0 및 5.0 (XDomainRequest 객체를 통해 부분 지원)
- Presto 기반 브라우저 (오페라 12.00 및 Opera Mobile 12부터 지원, Opera Mini는 제외)
- WebKit (사파리 4 이상, 구글 크롬 3 이상)
- 마이크로소프트 엣지 모든 버전
5. 1. 지원 브라우저 목록
| 레이아웃 엔진 | 브라우저 |
|---|---|
| Blink 및 크로미움 기반 | Chrome 28 이상,[8][9] Opera 15 이상,[8] 아마존 실크, 안드로이드 4.4+ WebView 및 Qt의 WebEngine |
| Gecko | 1.9.1 (Firefox 3.5,[10] SeaMonkey 2.0[11]) 이상 |
| MSHTML/Trident | 6.0 (인터넷 익스플로러 10)은 기본 지원.[12] 4.0 & 5.0 (인터넷 익스플로러 8 & 9)은 XDomainRequest 객체를 통해 부분적으로 지원.[13] |
| Presto 기반 | Opera 12.00[14] 및 Opera Mobile 12부터 CORS를 구현하지만, 오페라 미니는 제외.[15] |
| WebKit | Safari 4 이상,[16] Chrome 3 이상.[17] |
| 마이크로소프트 엣지 | 모든 버전.[18] |
6. CORS vs JSONP
CORS는 JSONP의 현대적인 대안으로 사용될 수 있다. CORS와 JSONP의 주요 차이점은 다음과 같다.
- JSONP는 GET 요청 방식만 지원하지만, CORS는 다른 유형의 HTTP 요청도 지원한다.
- CORS를 사용하면 웹 프로그래머가 XMLHttpRequest를 사용하여 JSONP보다 더 나은 오류 처리를 할 수 있다.
- JSONP는 외부 사이트가 손상될 때 크로스 사이트 스크립팅(XSS) 문제를 일으킬 수 있지만, CORS는 웹사이트에서 응답을 수동으로 구문 분석하여 보안을 강화할 수 있도록 한다.[1]
- JSONP는 CORS 지원 이전의 레거시 브라우저(오페라 미니 및 인터넷 익스플로러 9 이하)에서 작동할 수 있지만, CORS는 현재 대부분의 최신 웹 브라우저에서 지원된다.[24]
6. 1. CORS의 장점
- JSONP는 GET 요청만 지원하지만, CORS는 다른 유형의 HTTP 요청(PUT, DELETE 등)도 지원한다.
- CORS를 사용하면 웹 프로그래머가 XMLHttpRequest를 사용하여 JSONP보다 더 나은 오류 처리를 할 수 있다.
- JSONP는 외부 사이트가 손상될 경우 크로스 사이트 스크립팅(XSS) 문제를 일으킬 수 있지만, CORS는 웹사이트에서 응답을 수동으로 구문 분석하여 보안을 강화할 수 있다.[1]
6. 2. JSONP의 장점
JSONP의 가장 큰 장점은 CORS를 지원하지 않는 구형 브라우저(오페라 미니 및 인터넷 익스플로러 9 이하 버전)에서 작동할 수 있다는 것이다.[24] CORS는 현재 대부분의 최신 웹 브라우저에서 지원된다.참조
[1]
웹사이트
Cross-domain Ajax with Cross-Origin Resource Sharing
http://www.nczonline[...]
NCZOnline
2012-07-05
[2]
웹사이트
Fetch Living Standard
https://fetch.spec.w[...]
[3]
웹사이트
WebAppSec Working Group Minutes
https://www.w3.org/2[...]
[4]
웹사이트
Cross-Origin Resource Sharing
http://www.w3.org/TR[...]
[5]
웹사이트
Cross-Origin Resource Sharing (CORS) - HTTP {{!}} MDN
https://developer.mo[...]
2023-05-10
[6]
웹사이트
CORS errors - HTTP {{!}} MDN
https://developer.mo[...]
2023-07-04
[7]
문서
Retrieved on 2021-31-07
https://fetch.spec.w[...]
W3.org
[8]
웹사이트
Blink
http://www.quirksmod[...]
QuirksBlog
2013-04-04
[9]
뉴스
Google going its own way, forking WebKit rendering engine
https://arstechnica.[...]
Ars Technica
2013-04-04
[10]
웹사이트
HTTP access control (CORS) - MDN
https://developer.mo[...]
Developer.mozilla.org
2012-07-05
[11]
웹사이트
Gecko - MDN
https://developer.mo[...]
Developer.mozilla.org
2012-07-05
[12]
웹사이트
CORS for XHR in IE10
http://blogs.msdn.co[...]
MSDN
2012-12-14
[13]
웹사이트
cross-site xmlhttprequest with CORS
https://hacks.mozill[...]
MOZILLA
2012-09-05
[14]
웹사이트
12.00 for UNIX Changelog
http://www.opera.com[...]
Opera
2012-07-05
[15]
웹사이트
Opera Software: Web specifications support in Opera Presto 2.10
http://www.opera.com[...]
Opera.com
2012-07-05
[16]
웹사이트
cross-site xmlhttprequest with CORS ✩ Mozilla Hacks – the Web developer blog
https://hacks.mozill[...]
Hacks.mozilla.org
2012-07-05
[17]
웹사이트
59940: Apple Safari WebKit Cross-Origin Resource Sharing Bypass
http://osvdb.org/599[...]
Osvdb.org
2012-07-05
[18]
웹사이트
Microsoft Edge deverloper's guide
https://docs.microso[...]
2023-12-21
[19]
웹사이트
Voice Extensible Markup Language (VoiceXML) 2.1
https://www.w3.org/T[...]
W3.org
2012-07-05
[20]
웹사이트
Authorizing Read Access to XML Content Using the Processing Instruction 1.0
http://www.w3.org/TR[...]
W3.org
2012-07-05
[21]
웹사이트
Authorizing Read Access to XML Content Using the Processing Instruction 1.0 W3C - Working Draft 17 May 2006
http://www.w3.org/TR[...]
W3.org
2015-08-17
[22]
웹사이트
Cross-Origin Resource Sharing - W3C Working Draft 17 March 2009
http://www.w3.org/TR[...]
W3.org
2015-08-17
[23]
웹사이트
Cross-Origin Resource Sharing - W3C Recommendation 16 January 2014
http://www.w3.org/TR[...]
W3.org
2015-08-17
[24]
웹사이트
When can I use... Cross Origin Resource Sharing
http://caniuse.com/#[...]
caniuse.com
2012-07-12
[25]
웹인용
cross-site xmlhttprequest with CORS ✩ Mozilla Hacks – the Web developer blog
https://hacks.mozill[...]
Hacks.mozilla.org
2012-07-05
[26]
웹인용
Same-origin policy / Cross-origin network access
https://developer.mo[...]
MDN
[27]
웹인용
Cross-domain Ajax with Cross-Origin Resource Sharing
http://www.nczonline[...]
NCZOnline
2012-07-05
[28]
웹인용
Cross-Origin Resource Sharing
http://www.w3.org/TR[...]
[29]
웹인용
WebAppSec Working Group Minutes
https://www.w3.org/2[...]
[30]
웹인용
Fetch Living Standard
https://fetch.spec.w[...]
[31]
웹인용
Cross-Origin Resource Sharing (CORS) - HTTP {{!}} MDN
https://developer.mo[...]
2023-05-10
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com