[Codestates FE] 블로깅 챌린지 1주차 - CORS

🖌

velog에 CORS라는 검색으로 포스트를 찾으면 약 6126개의 포스트가 나온다. 기본적인 개념이긴 하지만, 개발을 시작한 사람이라면 누구나 만나봤을 개념이다. 대학교 3학년 때, React.js와 Node.js로 프로젝트를 진행했었는데 개발 경험이 전무했던 우리 팀은 이게 뭔지도 몰랐다. 그저 구글에 에러 메시지를 검색해서 StackOverflow에 계신 많은 전문가분들의 도움을 받곤 했다. Proxy 등의 방법으로 해결해본 경험은 몇 번 있지만, 기술 면접을 위해 개념부터 탄탄하게 정리하고자 한다.

SOP의 탄생

클라이언트는 브라우저를 통해 URL 주소로 누군가가 만들어 놓은 웹사이트를 이용했다. 누구나 데이터를 요청하고 응답할 수 있었다. 하지만 이러한 방식은 보안의 문제점이 존재한다. 해커가 원하는 요청대로 클라이언트가 요청한 것으로 위장해서 이루어지는 보안상의 문제점이 발생한다. 이를 CSRF 공격이라고 한다. 따라서 나타난 대안이 SOP이다.

SOP는 Same-Origin Policy의 줄임말로, 동일 출처 정책을 뜻한다. 한마디로 '같은 출처의 리소스만 공유 가능하다'라는 정책이다. 여기서 출처는 엄연히 브라우저에서 판단한다. 따라서 브라우저마다 기준이 다를 수 있다. 대다수 브라우저 출처 기준은 scheme + host + port로 일치 여부를 판단한다. 따라서 출처를 확인하고, 다르면 보내지 않는다.

SOP가 보안 측면에서는 꽤 좋은 대안이었지만, JSONP 등의 트릭을 이용해 요청을 우회하는 문화가 생겼다. 또한, 다른 리소스를 사용하게 될 일이 너무 많다. 이 문제 상황에서 필요한 것이 CORS이다.

📌 CORS

CORS란 다른 출처여도, 이미 예상되는 출처라면 서버에서 허용해주는 응답 헤더를 보내, 브라우저가 응답 결과를 보내준다. 이를 CORS(Cross Origin Resource Sharing)이라고 한다.

MDN에서는 CORS를 "추가 HTTP 헤더를 사용해 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제"라고 정의한다.

 

브라우저는 SOP에 의해 기본적으로 다른 출처의 리소스 공유를 막지만, CORS를 사용하면 접근 권한을 얻게 된다. 따라서 우리가 "CORS Error"라고 알고 있던 것은 SOP가 원인이었고, CORS 설정을 통해 서버의 응답 헤더에 'Access-Control-Allow-Origin'을 작성해 접근 권한을 주는 것이었다.

📌 CORS의 작동 방식

1) preflighted requests

실제 요청을 보내기 전, OPTIONS 메서드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지 확인한 후, 응답 헤더의 Access-Control-Allow_rigin으로 요청을 보낸 출처가 돌아오면 실제 요청을 보낸다. 만약 접근 권한이 없다면 브라우저에서 CORS 에러를 띄우게 되고 실제 요청은 전달되지 않는다.

2) simple requests

단순 요청은 특정 조건이 만족되면 프리플라이트 요청을 생략하고 요청을 보내는 것을 말한다. 쉽게 말하자면, 그냥 한 번에 요청과 응답을 주고받는다.

3) Credentialed Requests

인증정보를 포함한 요청은 헤더에 인증 정보를 담아내는 요청이다. 출처가 다를 경우 별도 설정을 하지 않으면 쿠키를 보낼 수 없다. 이 경우 클라이언트, 서버 양측 모두 CORS 설정이 필요하다.

클라이언트는 요청 헤더에 withCrendentials : true를 넣는다.
서버 측에서는 응답 헤더에 Access-Control-Allow-Credentials : true를 넣는다.
서버 측에서 Access-Control-Aloow-Origin을 설정할 때, 모든 출처를 허용한다는 뜻의 와일드카드(*)로 설정하면 에러가 발생한다.