리액트 프로젝트로 전환하면서 아마 저희 파트내 모든 분들이 CORS에러를 겪으셨을겁니다..
도대체 왜 생기는걸까요?
원일을 찾아보기 앞서 SOP정책에 대해 알아봅시다.
동일 출처 정책이란 어떤 출처에서 불러온 문서 혹은 스크립트를 검증하여 공격 가능성을 줄이는 정책입니다. 즉, 웹브라우저에서 보안을 위해 프로토콜, 호스트, 포트가 동일한 서버로만 Ajax요청을 주고받을 수 있도록 제한하는 정책이죠.
예를들어 제가 Google의 특정 서버에 요청을 보냈다고 가정합시다. 그런데 이 Google의 특정서버에 직접적으로 닿는게 아닌 Naver Cloud의 특정 서버를 거친다고 가정할게요.
그럼 웹브라우저에서는 Naver로 Post요청을 보냈겠죠? 하지만 Naver는 이 Post요청을 Google로 포워딩하고 Google에서 제 브라우저로 직접 Response를 브라우저로 직접 전송하게 된거에요.
그림으로 나타내면? 다음과 같죠.
이렇게 된 경우, 크롬 브라우저는 Post요청을 Naver로 보냈으나 Response는 구글로부터 받게 됩니다. 아무 문제 없어 보이지만 구글 서버에서 악성 코드를 담아 리턴할 수도 있죠. 즉, 요청하지 않은 출처로부터 Response를 받게 되니 위험할지도 모르는 겁니다.
XSS공격이 위의 예시에서 나타나는 해킹방법입니다. HTML에 악성 스크립트를 삽입해 클라이언트를 공격하는 해킹방법이죠.
그래서 이런 공격을 막기 위해 브라우저들은 SOP정책에 따라 위험한 문서들을 걸러냅니다. 하지만 최근들어 웹서비스 규모가 확대되고, 서버와 AJAX를 통해 통신하는 방식이 이루어지며 개발자입장으로써는 걸러내지 않아도 되는데! 이런 경우가 많아졌죠.
하이퍼데이터도 마찬가지입니다. 우리가 React에서 로그인을 했을때, PO로 요청을 보내지만 정작 PO가 아닌 ProAuth에서 응답을 해주죠. 사실 저희입장에선 ProAuth도 신뢰할 수 있는 어플리케이션이지만, 브라우저 입장에선 믿을수 없다는 거죠.
그래서 CORS정책이 생겼습니다. 개발자들의 부담을 덜기 위해서죠. CORS는 추가 HTTP헤더를 사용해 브라우저가 한 출처에서 실행중인 웹 어플리케이션에 엑세스 권한을 부여하도록 하는 매커니즘중 하나입니다. 다른 출처의 리소스를 요청할 때, 출처가 다른 AJAX요청이라도 서버단에서 데이터 접근 권한을 허용하는 정책이죠. 물론 브라우저단에서 해당 정책을 적용하는 건 아니고 웹서버나 WAS에서 CORS 정책을 적용하게됩니다.
[참고 ; CORS에러는 SOP를 위반했다는 에러입니다.]