CORS?

CORS란 Cross Origin Resource Sharing으로 브라우저가 자신이 아닌 다른 곳으로 부터
자원(리소스)을 접근할 수 있도록 서버가 허가해주는 HTTP 기반 메커니즘이다.

CORS

그렇다면 이 CORS 는 왜 탄생하게 되었는지 그 배경부터 알아보자.

웹 페이지가 점차 상호작용이 풍부한 애플리케이션이 되어감에 따라 여러 페이지의 리소스를 가져와 사용하게 되었는데, 악의적인 웹 공격으로 인해 브라우저 보안 정책이 필요했다.

이를 위해 같은 출처의 리소스만 요청할 수 있는 SOP (Same-Origin Policy), 동일 출처 정책을 도입했고,
이후 웹 보안 표준으로 적용되었다.

그래서 SOP는 어떤 출처(origin)에서 스크립트를 통해 다른 출처(origin)의 리소스에 접근하는 것을 제한하는 정책이다.

Origin

계속 CORS, SOP에서 계속 등장하는 Origin 이라는 것은

위 그림과 같이 프로토콜, 도메인(호스트 이름), 포트를 포함하는 개념이다.

SOP?

예시를 들어보면 다음과 같다.

https://mysite.com에 접속한다.

https://mysite.com에서 사용하는 여러 리소스 파일을 다운받게 된다.

스크립트를 통해 다른 origin인 리소스를 요청하는 경우(HTMLElement.innerHTML, XMLHttpRequest, Fetch API 등) 요청 자체는 할 수 있지만 리소스를 접근할 수 없게 제한하는 정책이 SOP 라고 볼 수 있다.

예외로,

일부 HTML 요소(img, script, link)는 다른 origin의 요청을 허용하지만 javascript를 통해 그 내용에 접근하는것은 제한된다.

ajax 요청의 경우 요청 자체는 가능하지만, 응답 데이터를 읽는것은 제한된다.

이전에는 프론트, 백이 따로 구성되지 않고 한번에 모든 처리가 같은 도메인안에서 가능했기에 다른 출처로 리소스를 요청하는것이 이상했기 때문에 SOP 준수에 어려움이 없었다.

하지만 웹이 발달하면서 다른 출처의 데이터, 리소스를 가져오거나 클라이언트(프론트)에서 백엔드 API를 호출하는 경우가 많아지기 시작했다.

그래서 SOP를 준수하면서 다른 출처의 리소스를 공유 할 수 있는 CORS 정책이 탄생하게 되었다.

CORS 에러 대응하기

SOP가 적용되어 다른 출처의 리소스를 차단하는 경우 CORS 에러가 발생한다.

정확히는 서버가 적절한 CORS 헤더를 제공하지 않아 리소스 요청이 SOP에 의해 차단되는 경우에 CORS 에러가 발생한다.

다시 말하면 서버가 적절한 CORS 헤더를 제공한다면 다른 출처, 즉 교차출처(cross-origin) 요청인 경우에도 리소스를 공유할 수 있다는 말이다.

CORS 에러를 대응하기 위해 헤더를 세팅하는 방법에는 두가지가 있다.

1. 서버에서 `Access-Control-Allow-Origin` 응답 헤더 세팅하기

서버에서 요청을 수락할 출처를 명시적으로 지정하는 방법이다.

// *로 설정하면 출처에 상관없이 리소스에 접근할 수 있다.
'Access-Control-Allow-Origin': <origin> | * 
 
// 직접 허용할 출처를 세팅할 수 있다.
'Access-Control-Allow-Origin': <origin> | www.othersite.com

교차출처 리소스를 호스팅하는 (보내주는) 서버가 실제 요청을 허가할 것인지

2. 프록시 서버 사용하기

웹에서 리소스를 직접 요청하는 대신, 프록시 서버를 사용해 리소스의 요청을 전달하는 방법이다.

예를 들면,

https://mysite.com 에서 https://api.mysite.com 로 데이터를 직접 요청하게 되면 CORS 에러를 일으키게 된다.

하지만 https://mysite-proxy.com 라는 프록시 서버에 리소스 요청을 보내 https://api.mysite.com 에 요청을 전달하게하고 반환된 응답을 다시 https://mysite.com 에 전달함으로써 CORS 에러를 피할 수 있게 된다.