CORS (교차 출처 리소스 공유)
쉽게 풀면
아파트 경비원이 "이 동 주민이 아닌 사람은 함부로 들여보내지 않는다"는 원칙을 지킨다고 해봅시다. 다만 사전에 등록된 방문자 명단에 있는 사람이라면 들여보내 줍니다. 웹 브라우저도 기본적으로 "지금 보고 있는 사이트(A)와 다른 사이트(B)로 몰래 요청을 보내는 것"을 막습니다. 이렇게 하지 않으면 악성 사이트가 사용자 몰래 은행 사이트에 요청을 보내는 등의 문제가 생길 수 있기 때문입니다. 그런데 실제로는 지도 API나 결제 서비스처럼 다른 출처의 서버 기능을 정당하게 써야 할 때가 많습니다. 이때 서버가 "이 출처(도메인)의 요청은 허용한다"는 응답 헤더를 미리 알려주면, 브라우저는 그 규칙에 따라 요청을 통과시켜 줍니다. 이 허용 규칙과 절차 전체를 CORS라고 부릅니다.
왜 중요한가
웹 애플리케이션이 프런트엔드와 백엔드를 서로 다른 서버·도메인으로 분리해 개발하는 구조가 보편화되면서, CORS는 웹 시스템 아키텍처와 보안을 다루는 논문에서 빠지지 않고 등장하는 주제가 되었습니다. 특히 마이크로서비스나 오픈 API처럼 여러 출처의 서비스가 서로 데이터를 주고받는 환경에서는 CORS 설정이 곧 시스템 간 연동 가능 여부를 결정하므로, 시스템 설계 논문에서는 아키텍처의 타당성을 뒷받침하는 세부 근거로 다뤄집니다. 또한 웹 보안 연구에서는 CORS 설정 오류가 실제 취약점으로 이어지는 사례가 많아, 보안 점검·자동 진단 도구를 다루는 연구에서도 핵심 검증 대상으로 언급됩니다.
논문에서는 이렇게 쓰입니다
이 문장은 화면을 보여주는 서버와 데이터를 처리하는 서버의 주소가 달라서 생기는 접근 차단 문제를, 허용할 출처를 미리 지정해두는 방식으로 해결했다는 뜻입니다.
이 문장은 보안 진단 연구에서 여러 공공 API 서버의 CORS 설정을 실제로 조사했더니, 출처를 제한하지 않고 전부 허용해둔 경우가 많아 보안상 취약할 수 있다는 점을 발견했다는 뜻입니다.
이 문장은 여러 개의 작은 서비스로 나뉜 시스템에서, 관문 역할을 하는 게이트웨이가 CORS 관련 처리를 한 곳에서 맡도록 설계해 개발과 관리를 단순화했다는 뜻입니다.
조금 더 깊게 보면
CORS는 실제로 두 종류의 요청 방식으로 나뉘어 동작합니다. 단순한 조건을 만족하는 요청은 브라우저가 바로 서버로 보내고 응답 헤더로 허용 여부를 확인하지만, 그렇지 않은 요청(예: 인증 정보를 포함하거나 특정 HTTP 메서드를 쓰는 경우)은 브라우저가 먼저 "이 요청을 보내도 되는지" 확인하는 사전 요청(preflight)을 별도로 보낸 뒤, 서버의 허가 응답을 받고 나서야 본요청을 전송합니다. 논문이나 기술 문서에서 Access-Control-Allow-Origin, Access-Control-Allow-Credentials 같은 응답 헤더 이름이 자주 등장하는 것도 이 때문이며, 이 헤더들의 조합을 어떻게 설정했는지가 시스템의 개방성과 보안 수준을 함께 보여주는 지표로 쓰이기도 합니다. 다만 CORS는 어디까지나 브라우저가 지키는 규칙이므로, 브라우저를 거치지 않는 서버 간 요청이나 별도의 프로그램을 통한 요청은 CORS 정책의 적용을 받지 않는다는 점도 함께 이해해 두면 좋습니다.
주의할 점
CORS는 편의를 위해 접근을 넓혀주는 개념 자체가 보안 위협이 아니라, 오히려 브라우저의 기본 차단 정책을 "안전하게 완화"하는 절차입니다. 허용 출처를 너무 느슨하게(예: 모든 출처 허용) 설정하면 크로스사이트 스크립팅이나 사이트 간 요청 위조 같은 공격에 노출될 위험이 커지므로, 꼭 필요한 출처만 허용하도록 좁게 설정해야 합니다.