CORS(Cross-Origin Resource Sharing)에 대해 알아보자

CORS가 나오기까지

옛날에는 웹 사이트와 같은 주소를 가진 서버에 자원을 요청해서 받는 일이 다반사였다. 오히려 주소가 다른 서버에 자원을 요청하면, 개인정보를 유출한다든지, 피싱 사이트 접속이라든지 보안상 위험한 일을 한다고 판단하는 것이 정상적이었다고 한다. 그래서 웹 브라우저는 같은 주소에 대한 자원 공유만 허용하도록 했다. 이 정책을 Same-Origin Policy(SOP)라고 한다.

그런데 지금은 프론트엔드 서버와 백엔드 API 서버가 따로 있는 경우가 다반사이다. 때문에 주소가 달라서 발생하는 이슈들이 생겨났다.

이 이슈를 해결하기 위해, 처음에는 우회 방법으로 JSONP를 이용하기 시작했다.

JSONP(Json with Padding)

JSONP는 HTML의 script 요소로부터 요청되는 호출은, 보안상 정책이 적용되지 않는다는 점을 이용한 우회 방법이다.

var script = document.createElement('script'); 
script.src = 'http://server.example.com/Users/1234?callback=somethingDoIt' 
document.getElementsByTagName('head')[0].appendChild(script);
function somethingDoIt(data){...} //callback method 

하지만 이 방법은 우회적인 방법이고, 여전히 보안적인 이슈가 있어서 좋은 방법은 아니었다. 하지만 이런 우회 방법에 대한 수요가 많았기 때문에 이대로 두기에는 아쉬운 점들이 있었다.

자 이제 CORS로 해결해!

그래서 표준적인 방법, CORS가 만들어졌다. CORS를 통해 웹 페이지의 주소와 다른 주소에 요청을 할 수 있도록 한 것이다.

하지만 이 방법은 프론트엔드만 바뀌어서 할 수 있는 것이 아니라, 백엔드(서버)에서 별도의 처리가 필요하다.

요약하자면 프론트엔드에서는 Request Header에 CORS와 관련된 옵션(Origin: ~)을 넣어서 요청을 전송해야하고, 백엔드에서는 Response Header에 해당 프론트의 요청을 허용한다는 내용(Access-Control-Allow-Origin: ~)을 넣어서 응답하는 것이다.

특이한 점은, 겉보기에는 한번만 Fetch 요청을 전송하는 것 같지만 CORS의 경우에는 HTTP의 OPTION 메소드를 통해 요청을 허용할 것인지를 묻고 OK 응답이 오면, 그 다음 GET, POST 등의 요청이 들어가 실행된다는 점이다.

그래서 서버에서는 이 OPTION 메소드에 대한 별도의 라우팅 처리를 해줘야하지만, 보통 라이브러리에서 해주기 때문에 개발을 할 때는 신경쓰지 않아도 되는 경우가 많다고 한다.

CORS에 대해 더 자세한 사용 방법이 궁금하다면, MDN을 참고하세요!