CORS, 왜 개발자들은 어려워할까?

커뮤니티에서는 CORS(Cross-Origin Resource Sharing)가 보안 기능이 아니라 오히려 동일 출처 정책(Same-Origin Policy, SOP)을 완화하는 기능이라는 점을 지적한다. SOP는 기본적으로 다른 출처(Origin) 간의 데이터 읽기를 차단하지만, CORS는 특정 출처의 JavaScript가 응답을 읽도록 허용하는 메커니즘이다. 따라서 요청 자체는 발생하며, 백엔드에서 이를 안전하게 처리하는 것이 중요하다는 의견이 다수다. 브라우저(Browser)가 이 정책을 강제한다는 점도 강조된다.

Zoom의 취약점은 localhost 서버에 대한 CORS 헤더 미설정에서 비롯되었다는 분석이 지배적이다. 글에서는 이를 AJAX 요청 대신 이미지 태그를 이용한 우회 방식으로 설명하며, 이는 브라우저의 localhost 정책을 악용한 것으로 보인다. 개발자들은 데이터 격리 아키텍처(Data Isolation Architecture)를 고려하지 않고 단순히 코드를 작동시키려다 보안 허점을 만든 사례로 지적된다. Access-Control-Allow-Origin 헤더 설정의 중요성이 부각된다.

많은 개발자들이 CORS를 디버깅하기 어려운 문제로 인식하며, 에러 메시지가 의도적으로 축소되어 있어 문제 파악이 어렵다는 의견이 많다. 특히 백엔드 개발자의 경우 일상적으로 CORS 이슈를 접하지 않아 주기적인 복습이 필요하다는 경험담도 공유된다. MDN 문서나 구체적인 예시를 통해 이해를 돕는 것이 중요하지만, 근본적으로 보안 모델(Security Model)에 대한 이해 부족이 문제라는 지적이 나온다.

CORS 이해 부족은 단순히 기술적 지식의 문제가 아니라, 웹 개발의 복잡한 보안 모델(Complex Security Model)에 대한 이해 부족과 연결된다는 분석이다. 클라이언트(Client), 브라우저(Browser), JavaScript 간의 상호 신뢰 관계와 브라우저의 보호 역할을 명확히 인지해야 한다. 일부에서는 개발자 간의 소통 부족이나 레거시 문제(Legacy Issues)로 인한 타협점(Compromise)이 CORS를 복잡하게 만들었다고 주장한다.

댓글에서는 동일 출처(Same Origin)로 프론트엔드와 백엔드를 호스팅하는 리버스 프록시(Reverse Proxy) 사용을 대안으로 제시한다. 이 경우 CORS 설정 없이 SOP(Same-Origin Policy)를 그대로 활용하고 CSP(Content Security Policy)로 강화할 수 있다. 또한, 브라우저 확장 프로그램(Browser Extension)이나 네이티브 앱(Native App)의 자체 서명 인증서 활용 등 다양한 기술적 해결책이 논의되었으나, Zoom 사례에서는 이러한 접근이 이루어지지 않았다.