[개요]
CORS 정책은 '외부 API를 사용하는 웹 서비스' 혹은 'Frontend / Backend를 구분하는 웹 서비스'를 배포할 때 종종 맞이하게 된다.
하지만 다양한 외부 공격으로부터 보안 취약점을 극복하기 위해 CORS 정책은 필요하다.
따라서 웹 서비스 개발과 배포에서 피할 수 없는 CORS 정책에 대해 알아보기 위해 이 포스팅을 준비하게 되었다.
[동일 출처 정책 (Same-Origin Policy)]
'Same-Origin Policy' 는 한 웹페이지의 스크립트가 다른 도메인, 프로토콜, 포트를 가진 리소스에 접근하지 못하게 하는 정책이다.
(JavaScript, AJAX, Fetch API 등 클라이언트 측 코드에만 적용되며, 서버간 통신에는 적용되지 않는다.)
여기서의 출처(Origin)란 '프로토콜' + '도메인' + '포트' 의 조합이다.
즉 Same-Origin Policy는 출처를 구성하는 3가지 중 어느하나라도 다르다면, 접근할 수 없다.
"https://example.com" 의 웹페이지는 "https://api.example.com" 에 접근할 수 없다. -> 도메인 차이
"https://example.com:443" 은 "https://example.com:8080" 에 접근할 수 없다. -> 포트 차이
이는 웹 서비스의 보안 취약점을 극복하기 위한 정책이지만 너무나 강한 폐쇄성을 가지고 있다.
예전 웹 서비스와는 달리 현대의 웹 서비스는 외부 API를 적극적으로 활용한다.
이 경우 SOP의 강한 폐쇄성은 필연적으로 서비스에 애로사항을 가져온다.
이러한 문제점을 극복하기 위해 CORS 정책이 등장하게 되었다.
SOP가 "서로 다른 출처의 리소스 접근을 원천 차단하여 보안을 강화" 하는 목적이었다면,
CORS는 "다른 출처와의 통신을 제한적으로 허용하되, 보안을 유지" 하는것이 목적이다.
[교차 출처 리소스 공유 (Cross-Origin Resource Sharing)]
"교차 출처" 즉 "출처가 교차한다" 라는 것의 의미는 "리소스를 주고 받으려는 대상의 Origin이 서로 다르다." 라는 것을 의미한다.
CORS와 SOP는 기본적으로 다른 출처(Origin)에 대한 요청을 차단한다.
SOP는 교차 출처 요청을 예외없이 차단하지만,
CORS는 서버가 허용가는 경우에만 교차 출처 요청을 허용한다는 차이점이 있다.
이 요청은 서버가 HTTP 헤더를 통해 허용할 수 있다.
즉, CORS는 서버가 허용하는 범위에서는 교차 출처가 가능하다는 것이다.
[CORS 에서 '교차 출처' 허용을 하는 방법]
1. 서버에서 "Access-Control-Allow-Origin" 응답 헤더 세팅
Access-Control-Allow-Origin Http 헤더를 이용하여 해결한다.
"https://example.com" 에서 "https://api.example.com"의 리소스를 요청하려면,
Access-Control-Allow-Origin 을 "https://api.example.com"로 설정한다.
스프링 부트를 사용한다면, 어노테이션을 사용하여 처리할 수 있다.
2. 프록시 서버를 이용하기
프록시 서버를 사용하는 방식은 "브라우저가 하나의 Origin과만 통신"하게 하는 방식이다.
그림으로 표현하자면 위와 같다.
브라우저는 오직 프록시 서버랑만 통신한다.
브라우저가 프록시 서버로 "백엔드 처리가 필요한 요청" , "DB 처리가 필요한 요청" 등 어떠한 요청이 오더라도 브라우저가 직접 백엔드 서버와 DB 서버에 요청할 수는 없다.
프록시 서버가 해당 요청을 처리하기 위해 백엔드 서버, DB 서버로 요청을 하여 진행하고, 그 결과 값을 프록시 서버를 통해 브라우저로 전달한다.
즉, 브라우저는 Cross-Origin 위반 자체를 할수가 없는 상황이 된다는 것이다.
[프록시 서버란?]
https://notorious.tistory.com/280
[Docker] nginx 역방향 프록시를 이용한 도메인 기반 서비스 (역방향 프록시 설명)
1. 역방향 프록시란 무엇인가? * '프록시 서버'란 무엇인가? 일반적으로 프록시는 정방향 프록시를 의미한다. 프록시는 클라이언트와 서버와의 직접적인 통신을 하지 못하도록 중간에서 통신을
notorious.tistory.com