CORS (Cross Origin Resource Sharing)

SOP는 2000년대 초반에 탈취한 데이터로 서버로 접속하는 것을 막기 위해 생겨난 기능입니다. 이 기능을 조금 완화 시켜, 특정 출처에서 제공하는 리소스에 대한 접근을 허용하는 게 CORS 입니다.

 

CROS는 웹 페이지가 다른 도메인의 리소스에 접근 할 수 있도록 하는 메커니즘이다. 웹 애플리케이션은 자주 다양한 도메인에서 데이터를 가져와야 하는데, 이 때 보안상의 이유로 기본적으로 동일 출처 정책이 적용된다(SOP, Same-Origin Policy). CORS는 이러한 정책을 일부 완화하여, 특정 출처에서 제공하는 리소스에 대한 접근을 허용한다.

 

• SOP 동일 출처 정책

동일 출처 정책은 웹 보안의 핵심 개념으로, 웹 애플리케이션에서 다른 도메인의 리소스를 직접 요청하는 것을 제한한다. 동일 출처 정책이 적용되는 경우, 웹 애플리케이션은 동일한 출처 (프로토콜, 도메인, 포트)에서만 리소스에 접근할 수 있다. 이 정책은 사용자의 데이터를 보호하고, 웹 사이트 간의 공격을 에방하기 위해 사용된다.

 

 

• CORS 작동 원리

CORS는 브라우저와 서버 간의 통신에서 HTTP 헤더를 사용하여 동작한다. 브라우저는 리소스를 요청할 때, 'Origin' 헤더를 포함하여 서버에 전송한다. 서버는 이를 확인한 후, 허용된 출처가 있다면 "Access-Control-Allow-Origin" 헤더를 포함하여 응답한다. 브라우저는 이 헤더를 확인하고, 허용된 출처라면 리소스에 대한 접근을 허용한다.

 

 

• 사전 요청 (Preflight Request)

CORS는 특정 조건에 따라 사전 요청이라는 개념을 도입한다. 이는 복잡한 요청을 수행하기 전에 서버에 사전 요청을 보내어 리소스에 대한 접근이 허용되는지 확인하는 과정이다. 사전 요청을 브라우저가 자동으로 처리하며, HTTP OPTIONS 메서드를 사용한다. 서버는 이에 대한 응답으로 허용되는 메서드, 헤더, 캐시 등을 반환한다.

 

 

• CORS 구현

CROS는 서버 측에서 구현되어야 한다. 서버는 요청을 받을 때 "Origin" 헤더를 확인하고, 허용된 출처인지 판단한 후 응답 헤더에 적절한 값을 설정한다. 이 과정은 서버 언어 및 프레임워크에 따라 다르게 구현될 수 있다. 일반적으로, 서버는 허용되는 출처를 정의하는 환경 변수나 설정 파일을 가지고 있어, 개발자가 쉽게 수정할 수 있다.

 

 

• CORS의 한계 및 보안 고려사항

CORS는 동일 출처 정책의 일부 완화를 허용하며, 여러 도메인 간의 통신을 가능하게 한다. 그러나 이를 잘못 구성하면 보안 문제가 발생할 수 있다. 예를 들어, 모든 출처에 대한 접근을 허용하면 악의적인 웹사이트가 사용자의 데이터를 탈취할 수 있다. 따라서 개발자는 허용된 출처를 신중하게 설정하고, CORS 구성을 정기적으로 검토해야 한다.