> For the complete documentation index, see [llms.txt](https://shhn0509.gitbook.io/javascript/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shhn0509.gitbook.io/javascript/web/ajax/cross-domain/cors-server.md).

# CORS: 서버(Server) 개발단 해결책

## 교차 출처 리소스 공유 

그래서 만들어진 추가 정책이 [교차 출처 리소스 공유(CORS, Cross-Origin Resource Sharing)](https://developer.mozilla.org/ko/docs/Web/HTTP/CORS)입니다.이 정책의 특징은 서버에서 외부 요청을 허용할 경우 Ajax 요청이 가능해집니다. 즉, 쉽게 말해 API서버에서 CORS를 통해 허용 된 외부 도메인에서 접근할 수 있도록 만들어 준다. 

웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화 한 스팩으로 서버와 클라이언트가 정해진 헤더(Header)를 통해 서로 요청이나 응답에 반응할지 결정하는 방식으로 교차 출처 리소스 공유(CORS) 명칭으로 표준화 되었습니다. CORS방식은 요청을 받은 웹 서버가 허용할 경우에는 다른 도메인의 웹 페이지 스크립트에서 데이터를 주고 받을 수 있게 허용합니다. 

즉, 허용 된 도메인이라면 Ajax 통신을 외부에서도 사용할 수 있습니다. 아래 그림을 살펴봅시다.

![](https://1609565946-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MQBEZ0w9UlpTQnX-DAe%2F-MR4dpAB1sEE_k0tmBQK%2F-MR4f8iZDTyarzkLR9Qv%2Fimage.png?alt=media\&token=fca5bb4e-38e8-460f-b19b-d11cf779e228)

A 서버의 JavaScript Code에서 Ajax 통신을 요청(`xhr.send()`)하면, B서버에 실제 요청이 아닌, [프리 플라이트 요청(preflight request)](https://developer.mozilla.org/ko/docs/Glossary/Preflight_request)을 먼저 수행합니다. 

{% hint style="info" %}
**프리 플라이트 요청(preflight request)**

교차 출처 리소스 공유 사전 요청은 본격적인 교차 출처 HTTP 요청 전에 서버 측에서 그 요청의 메서드와 헤더에 대해 인식하고 있는지를 체크하는 것이다.
{% endhint %}

이 과정에서 B 서버는 A 서버의 도메인이 접근 허용 권한이 있는지 확인합니다. A 서버 도메인에서 B 서버로 접근 허용이 가능해질 경우, 실제(Actual) 통신 요청/응답을 주고 받을 수 있게 됩니다. 

하지만! 이 방법은 B 서버에 CORS 설정이 되어있어야 접근이 가능합니다. 즉, 서버 개발자가 CORS 설정을 허용하지 않을 경우, 클라이언트 개발단에서는 SOP 보안 정책에 막혀 외부 데이터에 접근할 수 없습니다. 

즉, CORS는 서버개발단의 해결책이지, 프론트엔드 개발단에서 해결하는 방법은 아닙니다. 

그렇다면?! 프론트엔드 개발단에서 동일 출처 정책(SOP)문제를 해결하려면 어떻게 해야 할까요?

## 정리

SOP를 해결할 수 있는 방법 중 서버 측의 해결 방법은 CORS이다. 서버에서 CORS를 통해 외부 요청을 허용해 주면 Ajax 요청이 가능해진다. 

이것을 서버 개발단의 해결책이라고 하는 이유는 CORS 허용은 서버 개발자가 설정하는 것이기 때문에 만약 서버 개발자가 CORS 설정을 허용하지 않을 경우 클라이언트에서 서버의 자료에 접근할 수 없다.