웹 서버 관련 업무를 하다 보면 CORS 관련 문제가 빈번히 발생한다. express로 개발할 때는 별 생각 없이 cors 모듈을 설치하고 이것을 미들웨어로 등록해버리고 신경을 끊어 버렸다. 구현을 기능이 많아서 우선 순위에서 밀렸다고 어설픈 핑계를 대보고 싶다.
상황이 바뀌어서 Qt 6.4부터 포함된 QHttpServer를 이용해서 웹 서비스를 개발하게 되었다. node.js의 express 프레임워크와 웹 관련 모듈을 사용할 때와는 차원이 다른 어려움들이 밀려오고 있다.
개발 중에는 실제 서버와 웹 앱이 다르게 동작하는 경우가 빈번하다. Create-React-App 을 이용해서 자체 개발 서버를 이용하면서, DB와 같은 서비스는 다른 웹 서버를 통해서 이용하는 형태가 많이 유용하다. 이 경우에 주로 웹 서비스를 제공하는 웹 서버 쪽에 CORS 관련 허용 설정을 해줘야 한다.
CORS의 개념은,
에서 잘 설명되어 있다. 내가 정리해봤자 이 글보다 더 잘 설명할 자신이 없다. 이번에 CORS를 파악하기 위해 삽질을 하면서 확실히 알게 된 사실이 하나 있다.
CORS는 결과적으로 요청하는 웹 앱의 origin을 웹 서비스에서 허용하는 것이냐 그렇지 않느냐를 결정짓는다는 점이다. A라는 웹서버가 있다고 가정하자. 웹브라우저는 A서버로부터 웹페이지를 로드하고 웹앱을 실행하게 된다. 그리고 각종 서비스를 A서버로부터 요청하게 되는데, 이 경우에는 HTTP 요청에 포함되는 헤더 중 origin이라는 값이 당연히 A서버로 설정된다. A서버라고 간단히 표현했지만, 실제로는 http나 https와 같은 scheme, 호스트의 주소, 서비스하는 포트, 이 세 가지가 동일해야 같은 origin이라 판단한다.
그래서, 앞에서 살짝 예를 들었던 Create-React-App 을 이용해서 개발하는 경우에는, 같은 호스트 주소일 수는 있지만, 포트가 다를 것이기 때문에 CORS 문제가 발생하는 것이다.
착각하고 있었던 것이 이 CORS에 대한 정책에 대한 정보는 웹서버가 응답으로 넘겨주나 이것을 실제로 실행하는 것은 웹브라우저라는 것이다. 웹서버에서는 CORS로 허용하는 설정을
Access-Control-Allow-Origin: https://moonyl.github.io와 같이 응답할 수 있다. 브라우저가 https://moonyl.github.io로부터 웹페이지를 로드해서 실행하는 경우라면 origin 이 일치하여 통과가 되겠지만, 다른 개발 서버를 통해서 웹 앱이 실행되는 경우라면 브라우저에서 CORS 위반으로 오류를 발생 시킨다는 것이다.
고민할 것 없이,
Access-Control-Allow-Origin: *으로 한다면, 모든 다른 서버의 웹 요청을 받아들이도록 허용한다는 의미가 될 것이기 때문에, CORS 위반을 쉽게 회피할 수 있는 방법이 될 것이다. 하지만, 직관적으로도 보안상으로 위험해 보인다. 개발 중에서만 CORS를 모두 허용하도록 분기 처리해야 할 것이다.
