교차출처리소스공유(CORS) (Cross-Origin Resource Sharing)
쉽게 풀면
교차출처리소스공유는 원칙적으로 서로 다른 사이트끼리 정보를 주고받지 못하게 막는 규칙에 예외를 허용하는 방문 허가증과 같습니다. 예를 들어 A 사이트의 웹페이지가 B 사이트의 API에서 데이터를 받아와야 할 때, B 사이트가 "A 사이트는 접근해도 좋다"라고 미리 허락 목록을 지정해두면 브라우저가 해당 요청을 허용해줍니다. 이 허락은 서버가 응답 헤더를 통해 브라우저에 전달하는 방식으로 이루어집니다.
왜 중요한가
다양한 서비스가 서로 다른 도메인의 API를 호출하며 동작하는 현대 웹 환경에서 교차출처리소스공유는 필수적인 메커니즘이지만, 설정을 잘못하면 심각한 보안 허점이 될 수 있어 정보보안학 연구에서 정책 오설정 사례와 그 위험성이 자주 분석됩니다.
논문에서는 이렇게 쓰입니다
느슨한 CORS 설정의 실태를 조사한 연구 사례입니다.
설정 오류가 실제 공격으로 이어지는 과정을 검증한 연구 사례입니다.
조금 더 깊게 보면
교차출처리소스공유는 허용할 출처, 허용할 메서드, 인증정보 포함 여부 등을 서버가 세부적으로 지정할 수 있으며, 일부 요청은 실제 요청 전에 사전 확인 요청을 먼저 보내는 절차를 거칩니다. 허용 출처를 지나치게 넓게 설정하거나 인증정보 포함을 무분별하게 허용하면 보안 위험이 커집니다. 사전 확인 요청(preflight request)은 실제 요청을 보내기 전에 OPTIONS 메서드로 서버에 허용 여부를 먼저 묻는 절차로, 단순 요청 조건을 벗어나는 커스텀 헤더나 특정 메서드를 사용할 때 자동으로 트리거됩니다. 자격 증명을 포함하는 요청에서는 서버가 반드시 특정 출처를 명시적으로 지정해야 하며, 이 경우 와일드카드 출처 지정 자체가 허용되지 않도록 표준이 설계되어 있습니다.
주의할 점
교차출처리소스공유는 동일출처정책을 우회하는 기능이 아니라, 서버가 신뢰하는 범위 내에서만 예외를 허용하는 것이므로 설정 범위를 신중하게 관리해야 합니다. 응답 헤더에 모든 출처를 허용하는 와일드카드를 인증 정보 포함 요청과 함께 사용하는 것은 브라우저 표준에서도 금지되어 있어, 이런 오설정이 없는지 점검해야 합니다.