통합을 위해 SOP 한계를 극복하는 CORS 정책

#웹 #보안

작성 : 2024-04-14수정 : 2024-04-14

목차 펼치기

머리말

이 글에서는 웹 브라우저의 기본 정책인

같은 출처 정책(SOP, Same-Origin Policy)

과 그 한계를 살펴보며 CORS가 왜 중요한지, CORS 오류란 무엇인지와 해결하기 위한 방법에 대해서 알아본다.

SOP와 그 한계

기본적으로 웹 브라우저는 SOP를 따르며, 다른 출처의 리소스와 상호 작용하는 것을 제한한다. 만약 웹 브라우저가 이 정책을 따르지 않아서 다른 출처의 리소스에 자유롭게 접근할 수 있게 된다면, 쉽게 사용자 정보를 탈취하거나 조작하는 등 보안 취약성이 증가할 수 있다.

SOP는 다양한 위협을 모두 방어해줄

은 탄환

은 아니지만, 보안을 위한 기본적이고 필수적인 정책이라고 할 수 있다.

하지만 다른 출처의 리소스에 접근할 수 없게 된다면, 다양한 서비스 간의 통합이 불가능해진다. API를 통해 다양한 서비스가 통합되고 있는 현대의 웹 사이트와는 맞지 않는 것이다. 그렇기 때문에 CORS를 통해 제한된 환경에서 리소스를 공유할 수 있게 함으로써 보안과 통합 사이 균형을 유지한다.

CORS란?

Cross Origin Resource Sharing의 준말로,

웹 페이지가 다른 도메인의 리소스에 접근할 수 있게 허용

하는 웹 보안 정책을 말한다. 다양한 서비스들을 통합하는 모던 웹을 위해 브라우저에서 SOP를 제한적으로 완화하기 위해 사용한다.

CORS 오류란?

웹 페이지가 다른 출처의 데이터를 요청했을 때 SOP로 인해 제한되는 것을 말한다. 브라우저는 요청 출처와 대상 출처, 그리고 대상 서버의 CORS 헤더를 확인한 후 허용되지 않은 접근일 경우 CORS 오류를 발생시킨다.

이를 해결하기 위해 대상 서버의 HTTP 응답 헤더를 수정하거나, 프록시 서버를 이용할 수 있다.

HTTP 응답 헤더 CORS 설정

서버에서 HTTP 응답 헤더에 리소스 접근을 허용할 출처를 포함시킬 수 있다.

Access-Control-Allow-Origin
- 허용 출처 지정
Access-Control-Allow-Methods
- 허용 HTTP 메서드 지정
Access-Control-Allow-Headers
- 허용 헤더 지정
- 클라이언트는 사전 요청을 통해 헤더를 사용할 수 있는 지 확인한다.
Access-Control-Max-Age
- 사전 요청 결과 캐싱 시간 지정
Access-Control-Expose-Headers
- 브라우저가 응답에서 접근할 수 있는 헤더 지정
- 브라우저가 제공하는 기본 헤더 외에 서버에서 다른 헤더를 제공하고, 이를 사용할 필요가 있을 때 안전하게 노출할 추가 헤더를 명시할 수 있다.
Access-Control-Allow-Credentials
- 쿠키, HTTP/SSL 등의 인증 정보 포함 여부 지정
- 기본적으로 Cross-Origin 요청에 인증 정보는 포함하지 않는다.
- 보안에 중요한 문제이기 때문에, Access-Control-Allow-Origin에 명시적으로 도메인을 지정해야하며, 아스터리스크(*)를 사용할 수 없다.

프록시 서버 이용

클라이언트 측에서 프록시 서버를 사용해서 동일 출처 정책을 우회하여 서버에 접근할 수 있다. 이를 통해 별도의 CORS 설정이 없어도 서버 리소스에 접근할 수 있다.

CORS없이 API 호출하기

기본적으로 CORS는 웹 페이지에서 다른 출처의 서버로 리소스를 요청할 때만 적용된다. 브라우저가 SOP 제약을 따르기 때문이다.

즉, 직접 서버로 요청하면 CORS 정책이 적용되지 않는다.

이를 이용해서 API 테스팅 도구를 활용해 CORS 영향 없이 서버의 리소스를 요청할 수 있다.

대표적인 API 테스팅 도구 중 GUI로는

등이 있고, CLI로는

이 있다. Curl은 macOS나 리눅스에 기본적으로 설치되어있다.

그렇기 때문에 CORS는 브라우저 환경에서 중요한 보안을 제공하지만 서버 측에서도 인증 및 권한, 암호화 등의 보안 체계가 함께 구축되어야 한다.