[Web Development] CORS (Cross-Origin Resource Sharing) 이해하기

CORS 개요

CORS는 Cross-Origin Resource Sharing의 약자로, 다른 출처(origin)에서 자원을 공유할 수 있도록 하는 메커니즘입니다. 웹 페이지가 다른 도메인의 자원에 접근하려고 할 때, 보안상의 이유로 브라우저는 동일 출처 정책(Same-Origin Policy)을 적용합니다. 이 정책은 웹 페이지가 자신과 동일한 출처에서만 리소스를 로드하도록 제한합니다. 그러나 CORS를 사용하면 웹 애플리케이션은 이 제한을 우회하고 다른 도메인의 리소스에 접근할 수 있습니다.

CORS 작동 방식

CORS는 HTTP 헤더를 사용하여 도메인 간에 자원을 공유할 수 있도록 합니다. 웹 애플리케이션은 HTTP 요청을 보낼 때 ‘Origin’ 헤더를 포함하여 요청을 보냅니다. 이 헤더는 요청이 시작된 웹 페이지의 출처를 나타냅니다. 서버는 이 헤더를 확인하고, ‘Access-Control-Allow-Origin’ 헤더를 응답에 포함하여 해당 출처에서의 요청을 허용할지 결정합니다.

CORS 작동 방식

CORS의 중요성

CORS는 웹의 중요한 보안 메커니즘입니다. 웹 애플리케이션은 종종 다른 도메인의 API를 사용하여 데이터를 가져오거나, CDN(Content Delivery Network)을 통해 이미지나 스크립트를 로드합니다. 이러한 도메인 간의 자원 공유는 웹의 핵심 기능 중 하나이지만, 동일 출처 정책 없이는 보안 위협이 될 수 있습니다.

CORS는 어떤 리소스가 허용되고 어떤 리소스가 차단되는지를 결정하는 규칙을 제공합니다. 이 규칙은 웹 애플리케이션의 HTTP 응답 헤더에 의해 설정됩니다.

예를 들어, 웹 애플리케이션 A가 다른 도메인의 리소스에 접근하려고 할 때, 그 도메인의 서버는 ‘Access-Control-Allow-Origin‘ 헤더를 사용하여 웹 애플리케이션 A의 접근을 허용할 수 있습니다. 이 헤더가 없거나 웹 애플리케이션 A의 출처를 허용하지 않는 값이 설정되어 있으면, 브라우저는 리소스에 대한 접근을 차단합니다.

동일 출처 정책(Same-Origin Policy)이 없다면, 웹 애플리케이션은 다음과 같은 보안 위협에 노출될 수 있습니다.

  • 사이트 간 스크립팅 공격 (Cross-Site Scripting, XSS): 악의적인 스크립트가 웹 애플리케이션에 삽입되어 사용자의 데이터를 탈취하거나 조작하는 공격입니다. 동일 출처 정책이 없다면, 악의적인 스크립트가 다른 도메인에서 로드되어 실행될 수 있습니다.
  • 사이트 간 요청 위조 공격 (Cross-Site Request Forgery, CSRF): 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행동을 하도록 만드는 공격입니다. 동일 출처 정책이 없다면, 웹 애플리케이션은 다른 도메인의 요청을 받아들일 수 있으므로 CSRF 공격에 취약해집니다.

CORS(Cross-Origin Resource Sharing)는 이러한 보안 위협을 방지하면서도 필요한 경우 다른 도메인의 자원을 안전하게 사용할 수 있도록 하는 메커니즘입니다. CORS는 브라우저가 서버에게 자원을 요청할 때 추가적인 HTTP 헤더를 사용하여, 서버가 다른 도메인의 자원 요청을 허용하는지를 확인합니다.

CORS 스펙 문서

CORS에 대한 자세한 사항은 W3C의 공식 스펙 문서를 참조하시면 됩니다. 이 문서는 CORS의 작동 방식, HTTP 헤더의 사용 방법, 에러 처리 방법 등에 대한 자세한 정보를 제공합니다.

WC3 : Cross-Origin Resource Sharing

동일 출처(origin) 확인

CORS에서 동일 출처(origin)를 판단할 때, scheme, host, port 요소가 모두 동일한지 검사를 합니다. 이 중 한가지 라도 다르다면 동일한 출처(origin)으로 판단하지 않습니다.

Understanding "same-site" and "same-origin"

The Web Origin Concept – Origin of a URI

WebSocket을 활용한 실시간 채팅 앱을 구현하면서, 해당 개념을 깊게 이해하지 못해 애를 먹었는데요. 로컬에서 정상 동작하던 채팅 앱을 서버에 배포하면서, JavaScript 단에서 SockJS 생성시에 403 Forbidden 응답 코드가 리턴되었습니다.

결과적으로 서버단에서 registerStompEndpoints 메서드에 EndPoint를 추가하는 코드에 .setAllowedOrigins으로 특정 도메인을 허용하면서 문제를 해결하였습니다. (환경 변수 HOST_ENDPOINT를 통해 도메인을 참조합니다.)

예를 들어 https://chat.example.com 도메인으로 요청하는 경우, JavaScript 단에서 SockJS 생성시에 http 혹은 https에 따라, ws 혹은 wss 프로토콜로 업그레이드(wss://chat.example.com)를 합니다.

이런 경우에, scheme(프로토콜)이 변경되어 CORS에 의해 동일 출처(origin)가 아닌 것으로 판단되기 때문에 403 Forbidden 응답 코드가 리턴되었던 것입니다.

이 글은 카테고리: Web Development에 포함되어 있습니다. 고유주소를 북마크하세요.

댓글 남기기