많은 웹 개발자들이 교차 출처 리소스 공유(CORS: Cross-Origin Resource Sharing)의 복잡성을 제대로 이해하지 못해 심각한 보안 취약점을 만들고 있다는 지적이 나왔습니다. 특히 2019년 줌(Zoom)에서 발견된 치명적인 보안 문제는 개발자들이 CORS를 우회하려다 발생한 대표적인 사례로 꼽힙니다.
줌은 사용자가 화상 회의 링크를 클릭하면 로컬 머신에서 실행 중인 웹 서버(http://localhost:19421)에 요청을 보내 네이티브 줌 앱을 실행하도록 설계되었습니다. 이 과정에서 줌은 일반적인 AJAX 요청 대신 이미지 로딩을 통해 CORS 정책을 우회하는 편법을 사용했습니다. 브라우저는 로컬호스트(localhost) 서버에 대한 CORS 정책을 특정 상황에서 무시하는 경향이 있는데, 줌은 이를 악용해 이미지의 크기로 서버의 응답 상태를 인코딩하는 방식을 택했습니다. 하지만 이는 줌 웹사이트뿐만 아니라 인터넷상의 모든 웹사이트가 로컬 줌 앱에 명령을 내리고 응답에 접근할 수 있게 만드는 심각한 보안 구멍이 되었습니다.
이러한 문제는 줌이 CORS의 본질적인 목적을 간과했기 때문에 발생했습니다. CORS는 웹 애플리케이션이 다른 출처(origin)의 리소스에 안전하게 접근할 수 있도록 브라우저가 강제하는 보안 메커니즘입니다. 줌의 경우, 로컬 웹 서버가 `Access-Control-Allow-Origin` 헤더를 `https://zoom.us`로 설정했다면 오직 줌 웹사이트에서 실행되는 자바스크립트(JavaScript)만이 로컬 서버와 통신할 수 있었을 것입니다. 또한, `Content Security Policy` 헤더를 통해 아이프레임(iframe) 내 렌더링을 차단하는 등의 추가적인 보안 조치도 가능했습니다. 개발자들이 단순히 기능을 구현하는 데 급급하여 CORS를 우회하려 들면, 이처럼 예상치 못한 심각한 보안 문제에 직면할 수 있습니다.
이 사례는 개발자들이 CORS와 같은 웹 보안 메커니즘을 단순히 작동을 방해하는 요소로 여기기보다, 사용자 데이터를 보호하고 안전한 웹 환경을 구축하기 위한 필수적인 요소로 이해해야 함을 보여줍니다. 스택 오버플로우(Stack Overflow) 등에서 흔히 볼 수 있는 불안정한 CORS 설정 예시들은 이러한 문제의식을 더욱 고조시킵니다. 웹 개발자 교육을 강화하고, 보안을 고려한 설계 원칙을 확립하는 것이 시급합니다.