CORS, Cross Origin Resource Sharing
두괄식으로, 쉽게 얘기하면 한 사이트에서 주소가 다른 사이트 서버에 API 요청을 보낼때 자주 접하는 오류이다.
예를 들어보자, URL이 'Banana.com'인 사이트에서 'Peach.com'인 사이트에 API로 정보를 받아오기 위해 Front-end에서 HTTP 요청을 보냈을때, 미리 어떤 설정을 하지 않으면 CORS 에러가 발생한다.
Postman에서 get 요청으로 보낼때는 되던데요...?
그 이유는 CORS 에러는 브라우저에서 발생하는 문제이기 때문이다. ex) chrome, safari
CORS 문제로 요청을 막는 것은 타 서비스의 API가 아니라 브라우저이다.
그럼 왜 브라우저는 CORS 에러를 토해내면서 우리의 요청을 막는가? 왜 막냐고..
브라우저 입장에서 생각해보자... 너라면 믿겠는가..?
너가 여기 저기 사이트 돌아다니면서 정체불명의 html,css,js 파일들을 차곡 차곡 쌓았자나.. 그걸 어떻게 믿겠냐는 말이다.
이 불순한 의도를 가지고 착한 유저들의 쿠키에 접근해서 개인정보를 갈취할지 말지 너를 으떠케 믿겠는가? 그래서 막았다.
즉, 너가 정상적으로 사용하는 웹 서비스들을 이용하면서 로그인 정보, 개인 정보들을 옳바르게 쿠키나 스토리지에 차곡차곡 쌓아뒀다. 근데 이 불순한 놈들이 나의 영역에 침범해서 소중한 개인 정보를 약탈해가는 것을 방지하기 위해서 이러한 장치를 설계했다.
솔직히 CORS는 억울하다.
사실 그의 충고는, "어떠한 녀석이 장벽을 세워서 너의 요청을 막고있으니, CORS를 풀어서 너의 요청을 옳바르게 통과시켜라." 라는 깊은 뜻이다.
여기서 막는 우리의 적은 바로 SOP이다.
그렇다면 SOP는 또 무엇인가.
Same-Origin Policy(동일 출처 정책)의 약자이니라.
동일 출처(url)끼리만 API 등의 데이터 접근이 가능하게 막는 것이다. 그러니 동일 출처가 아닌 경우에는 CORS란 것을 허용해주라는 뜻이다.
브라우저에서 기본값은 동일 출처가 아니라면 API 등 데이터 전달이 불가능하게 하는 것이다.
하지만 웹 생태계가 다양하고 복잡해지면서 서로 다른 서비스들간에 데이터 전달이 불가피한 상황이 많이 발생한다. 그래서 웹 개발자들과 CORS가 정모를 하게 되었다.
이말이야
예전에는 JSONP 같은 방법을 많이 사용했지만. 이런 문제들을 합의해서 출처들간에 합법적으로 허용하기 위해 어떤 기준을 충족시키면 리소스 공유가 되도록 만들어진 메커니즘이 바로 CORS!!!! 교차 출처 자원 공유 방식이다.
이말이야
그럼 으뜨케 해결하는가.
요청을 받는 서버(백엔드)에서 이걸 허락할 다른 출처들을 미리 명시한다. 백엔드 프레임워크 기본서를 보면 CORS 옵션을 넣는 방법들이 마련돼있다. 여기다 허용할 사이트들을 적어두면 이 서버로 언제든지 HTTP 요청을 보낼 수 있다. 아무나 보내도 되는 요청의 경우, 일반적으로 별표나 와일드카드를 적어두면 누구나 쓸 수 있다.
또, 브라우저는 이처럼 다른 출처끼리의 요청이 보내질 때는 요청에 Origin이라는 header를 추가한다.header는 데이터가 다른 곳으로 보낼 때, 데이터 맨 앞쪽에 붙은 보충 정보라고 보면 된다. 받는 쪽의 IP 주소, 사용할 프로토콜이나 옵션 등이 담긴다. Origin에는 요청하는쪽의 scheme과 도메인, 그리고 포트가 담긴다.
scheme(프로토콜)이란, 요청할 자원에 접근할 방법(http,ftp,telnet...)
이 요청을 받은 타 서비스의 API 서버는 답장의 헤더에 지정된 Access-Control-Allow-Origin 정보를 실어서 보낸다. 그럼 브라우저가 Origin에서 보낸 출처값이 서버의 답장 헤더에 담긴 Access-Control-Allow-Origin에 똑같이 있으면, 안전한 요청으로 간주하고, 응답 데이터를 받아오게 된다.
이상 더 자세한 내용은 다음 블로깅에 정리한다.
