화상회의 플랫폼 줌(Zoom)에서 과거 발견된 로컬 웹서버 취약점은 웹 개발자들 사이에서 교차 출처 리소스 공유(CORS: Cross-Origin Resource Sharing)에 대한 이해 부족이 얼마나 심각한 보안 문제로 이어질 수 있는지 명확히 보여주었습니다. 줌은 사용자의 로컬 머신에 웹서버(localhost:19421)를 띄워 네이티브 앱을 실행했는데, 이때 일반적인 비동기 자바스크립트 및 XML(AJAX) 요청 대신 이미지 로드를 통해 서버의 상태 코드를 전달하는 방식으로 CORS 정책을 우회하려 했습니다.
이러한 우회 시도는 브라우저가 localhost 웹서버의 CORS 헤더를 무시한다는 잘못된 가정에서 비롯된 것으로 보입니다. 실제로는 크롬(Chrome)을 포함한 대부분의 브라우저는 localhost 웹서버에도 CORS 헤더를 존중하며, 서로 다른 localhost 포트 간의 프론트엔드-백엔드 통신도 교차 출처 요청으로 처리합니다. 줌은 AJAX 요청이 CORS 정책에 의해 차단되자, 이미지 크기를 이용해 응답을 해킹하는 방식으로 우회를 시도했고, 그 결과 줌 웹사이트뿐만 아니라 인터넷의 다른 웹사이트들도 사용자 동의 없이 네이티브 클라이언트의 특정 동작을 트리거하고 응답에 접근할 수 있는 심각한 보안 취약점이 발생했습니다.
더 안전한 구현 방식은 로컬 웹서버가 REST API를 제공하고, `Access-Control-Allow-Origin` 헤더를 `https://zoom.us`로 설정하여 오직 줌 도메인에서 실행되는 자바스크립트만 로컬 웹서버와 통신하도록 제한하는 것입니다. 하지만 줌의 사례는 많은 개발자가 CORS를 단순히 귀찮은 장애물로 인식하고 우회하려는 경향이 있음을 드러냈습니다. 스택 오버플로우(Stack Overflow)에 `Access-Control-Allow-Origin` 관련 질문이 넘쳐나고, 심지어 일부 개발 가이드에서도 불안정한 기본값을 권장하는 경우가 있다는 점은 CORS에 대한 광범위한 혼란을 방증합니다.
CORS는 웹 보안의 핵심 요소인 동일 출처 정책(Same-Origin Policy)을 완화하면서도, 악의적인 웹사이트가 사용자의 동의 없이 다른 출처의 리소스에 접근하여 민감한 정보를 탈취하거나 원치 않는 동작을 유발하는 것을 막기 위한 중요한 보안 장치입니다. 개발자들이 CORS의 복잡성을 이유로 이를 제대로 이해하지 못하거나 우회하려 할 때, 줌 사례처럼 로컬 시스템의 권한 있는 기능이 외부 웹사이트에 노출되는 심각한 보안 구멍이 발생할 수 있습니다. 이는 개발자들이 단순히 코드를 동작시키는 것을 넘어, 웹 보안 모델과 위협 모델을 정확히 이해하는 것이 얼마나 중요한지 보여줍니다.