[🍎CS] CORS

웹 개발자라면 한 번쯤은 만나봤을 CORS 정책... 나 역시 프로젝트 진행 중 이 시뻘건 에러를 처음 보고 당황했던 기억이 있다. 이번 기회에 확실히 CORS에 대해 개념을 짚어보도록 하자~! 고고씡

CORS란 무엇인가

다른 출처의 리소스 공유에 대한 허용/비허용 정책

이렇게만 보면, 당최 무슨 소리인지 알 수 없으니 하나씩 처음부터 뜯어보도록 하자. 먼저 CORS는 Cross-Origin Resource Sharing의 줄임말로, 직역하면 교차 출처 리소스 공유 라는 뜻이다. 여기서 "교차(cross)출처"라는 것은 "(엇갈린) 다른 출처"를 의미한다고 볼 수 있는데, 출처(origin)이라는 건 또 무엇인가~?

출처(origin)

우리가 어떤 사이트를 접속할 때 인터넷 주소창에 치는 URL은 하나의 문자열 같지만 사실은 다음과 같은 여러 개의 구성요소로 이루어져 있다.
1) protocol(scheme)
2) host: 사이트 도메인
3) port: 포트번호
4) path: 사이트 내부 경로
5) query string: 요청의 key와 value 값
6) fragment: 해시태그

CORS를 이해하는 데 있어 중요한 것은 다음 세가지이다
origin: protocol + Host + Port

즉 출처라는 것은 protocol과 host와 port까지 모두 합친 url을 의미한다.

SOP(same-origin policy)

동일한 출처에서만 리소스를 공유할 수 있다는 정책

동일 출처 정책이 필요한 이유

사실 출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경은 꽤 위험한 환경이다. 만일 제약이 없다면 해커가 여러 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다. (XSS: Cross-Site Scripting) 이러한 악의적인 경우를 방지하기 위해 SOP 정책으로 동일하지 않는 다른 출처의 스크립트가 실행되지 않도록 브라우저에서 사전에 방지하는 것이다.

같은 출처와 다른 출처 기준

두 개의 출처의 다름 유무를 판단하는 기준은 위에서 origin이 무엇인가 에서 알 수 있다. 출처의 동일함은 Protocol, Host, Post 이 3가지만 동일하다면 동일 출처로 판단한다.

정리하자면 같은 프로토콜, 호스트, 포트를 사용한다면, 그 뒤의 다른 요소는 다르더라도 같은 출처로 인정된다. 반대로 이 세가지중 하나라도 자신의 출처와 다를 경우 브라우저는 정책상 차단하게 된다.

출처 비교와 차단은 브라우저가 한다

위에서 계속 브라우저에 굵은 글씨를 친 것을 눈치챘는가. 차단하는 주체는 누구? 바로 브라우저이다. 아무래도 서버에 요청을 하다보니 무슨 에러가 뜨면 서버 문제인가 생각하기 쉬운데 출처를 비교하는 로직은 서버에 구현된 스펙이 아닌 브라우저에 구현된 스펙이다.

사실 서버는 리소스 요청에 대한 응답은 깔끔히 해주었다. 그러나 브라우저가 이 응답을 분석해서 동일 출처가 아니면, CORS 에러를 내뿜는 것이다. 그래서 브라우저에는 에러가 뜨지만, 서버 쪽에서는 정상적으로 응답을 했다고 하기 때문에 난항을 겪는 것이다. 즉, 응답 데이터는 멀쩡하지만 브라우저단에서 받을 수 없도록 차단을 한 것이다.

CORS 정책의 필요성

SOP 좋다 이거야. 하지만 인터넷은 여러 사람들에게 오픈된 환경이고 이런 환경에서 웹페이지의 다른 출처에 있는 리소스를 가져와 사용하는 걸 무작정 막을 수도 없는 노릇. 그래서 몇 가지 예외 조항을 두고 다른 출처의 리소스 요청이라도 이 조항에 해당할 경우에는 허용하기로 했는데, 그 중 하나가 바로 CORS 정책을 지킨 리소스 요청이다. (=SOP 정책을 위반해도 CORS 정책에 따르면 다른 출처의 리소스라도 허용한다는 뜻!)

그럼 어떻게 하면 CORS 정책을 따르며 SOP 정책을 회피할 수 있는지 지금부터 함께 알아보자!

브라우저의 CORS 기본동작 살펴보기

클라이언트에서 HTTP 요청헤더에 Origin을 담아 전달

브라우저는 요청헤더에 Origin이라는 필드에 출처를 함께 담아 보낸다.

서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달

이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더에 Access-Control-Allow-Origin이라는 필드를 추가하고 '이 리소스를 접근하는 것이 허용된 출처 url'을 내려보낸다.

클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.

이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 Origin을 비교해본 후 차단할지 말지를 결정한다. 만약 유효하지 않다면 그 응답을 사용하지 않고 버린다(CORS 에러!!)

클라이언트측에서 현재 자신이 속한 출처(origin)을 기준으로 다른 출처에 API를 요청하게 되면 브라우저에서 이 요청으로 넘어오는 경과가 안전한지 판단하는데, 응답을 보내는 출처가 자신이 속한 출처가 아닌 다른 출처여도 서로 예상되는 출처라면 요청에 대해 허용해주는 응답 헤더를 보냄으로써, 브라우저가 응답 결과를 보여주는 것이다.

해결방법

CORS 에러는 server에서 해결할 수도 있고, client에서 해결할 수도 있다. 서버에서 해결하는 방법은 CORS 미들웨어를 사용하거나, Access-access-control-allow-origin 헤더를 세팅해주면 된다. 그런데 만약, 서버를 수정할 수 없거나 Open API를 사용하는 경우에는 클라이언트에서 처리해줘야 한다. 클라이언트에서 CORS 에러를 해결하는 방법은 바로 프록시 서버를 이용하는 것이다!

프록시 서버란, 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 서버를 가리킨다. 즉 프론트에서 CORS 에러를 핸들링하는 것은 서버로 가기 전에 프록시 서버를 거쳐서 출처를 response와 같게 수정하고, 서버에 접근하도록 하는 것이다.

---

참고사이트:https://www.datoybi.com/http-proxy-middleware/