CORS에 대하여

프로젝트에서 CORS 에러를 해결한 적이 있다. 학과생 때 진행했던 프로젝트인데 복기 과정에서 CORS에 대한 완전한 이해가 동반되지 못했다고 생각이 들어서 이번 기회에 못을 박고 넘어가자. 먼저 CORS란 무엇인지 짚고 넘어가자. CORS란? CORS 는 Cross Origin Resource Sharing 의 약자로 애플리케이션을 통합하기 위한 매커니즘 이다. 여기서의 매커니즘 은 한 도메인에서 로드되어 다른 도메인에 있는 리소스와 상호 작용하는 클라이언트 웹 애플리케이션에 대한 방법을 정의한다. 이때 이러한 작업은 HTTP-header를 이용해서 이루어지는데 이를 CORS 라고 부른다. 솔직히 나는 이 정의가 좀 여렵다. 내가 이해한 느낌으로 재정의 해보자. * CORS 는 다른 오리진( cross-origin )에서 리소스를 요청할 때 보안을 위해서 HTTP-header 를 이용해 서버에서 믿을만한 origin 인지 확인하고 그에 맞는 응답을 제공하는데 이러한 매커니즘을 CORS 라고 한다. 크로스 오리진(Cross-Origin)이란? cross-origin 이란 다음 중 한 가지라도 다른 경우를 말한다. * 프로토콜 * http와 https는 프로토콜이 다르다. * 도메인 * domain.com과 other-domain.com은 다르다. * 포트 번호 * 8080포트와 3000포트는 다르다. CORS는 꼭 필요한가? 답을 먼저 말하자면 꼭 필요하다. 과거에는 크로스 사이트 요청 위조(CSRF) 문제가 많이 발생했다. Cross Site Responce Forgery(CSRF) 은 사용자가 인증한 세션에서 웹 애플리케이션이 정상적인 요청과 비정상적인 요청을 구분하지 못하는 점을 악용하는 공격 방식으로, 웹 애플리케이션이 사용자의 요청이 실제 사용자가 전송한 것인지 확인하지 않는 경우에 자주 발생한다. CSRF 에 대한 더 자세한 내용은 친절하게 설명해주는 https://nordvpn.com/ko/blog/csrf/ 를 참고하자. 이러한 문제를 해결하기 위해서 이제는 모든 브라우저가 동일 오리진 정책 을 채택한다. 동일 오리진 정책 말그대로 동일한 오리진에서 오는 요청만을 허락하는 정책이다. 클라이언트 URL의 프로토콜, 포트 및 호스트 이름은 모두 클라이언트에서 요청하는 서버와 일치해야 한다. 이는 다른 오리진에서의 확인되지 않은 요청을 사전에 방지하는 정책이기도 하다. CORS를 사용했던 경험 진행했던 프로젝트의 간단한 시스템 아키텍처는 이미지에서 처럼 React 를 이용한 클라이언트와 Spring Boot 를 이용한 백엔드 서버가 독립적으로 존재했다. API 테스트 과정에서 클라이언트 localhost:3000 과 localhost:8080 은 cross-origin 상황이었다. 이는 당연하게도 클라이언트에서 백엔드 서버에 API 요청 시 CORS Error 를 발생시켰다. 간단한 해결 방법을 채택했지만(서버 측에서 3000 포트를 승인하게하는 방법) 직접 문제를 대면하고 해결했던 좋은 경험이었다. refer - https://aws.amazon.com/ko/what-is/cross-origin-resource-sharing/ - https://hannut91.github.io/blogs/infra/cors - https://nordvpn.com/ko/blog/csrf/