HTTP
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다.
클라이언트(브라우저)의 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송된다. 각각의 개별 요청들은 서버로 보내지고, 요청을 처리한 후 응답을 제공한다.
클라이언트
사용자 에이전트, 클라이언트는 주로 웹 브라우저이지만 무엇이든 될 수 있다.
항상 요청을 보내는 객체이다. 결코 서버가 될 수 없다.
브라우저는 페이지를 구성하기 위한 HTML, 스크립트 등의 리소스들을 가져와 웹 페이지를 갱신한다.
Proxy
웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다. 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않는다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시라고 부릅니다.
CORS
교차 출처 리소스 공유 (Cross-Origin Resource Shareing)
추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.
출처?
https://www.google.com/search?q=cors...
-
https
프로토콜(scheme) -
www.google.com(:portnumber)
URL의 호스트, 즉 hostname(URL의 도메인 이름)와 함께, 포트 (en-US)가 존재하는 경우 ':'과 그 뒤의 port를 포함하는 USVString 문자열 -
/search
path -
?q=...
qeury string
"출처"의 같고 다름의 기준은?
url의 구성 요소 중 scheme(protocol), host, port 가 동일하면 동일한 출처라고 간주한다.
왜 이런 정책이?
개발자 도구를 열어보면 웹 페이지의 생김새가 어떻게 생겼는지 대략적으로라도 확인해볼 수 있다. 그 뜻은 보안에 취약할 수 있다는 것이다.
이래서 다른 출처의 어플리케이션이 서로 통신하는 것에 제약이 없다면 악의를 가진 사용자가 정보를 탈취하거나, 보안적으로 큰 이슈가 생길 수 있다.
CORS 동작 방식
보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 예를 들어, XMLHttpRequest와 Fetch API는 동일 출처 정책을 따른다. 즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 합니다.
여기서 브라우저는 요청 헤더에 origin이라는 필드에 요청을 보내는 출처를 담아보낸다.
이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin(이 리소스를 접근하는 것이 허용된 출처)이라는 값을 준다.
이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.
이것은 기본적인 흐름이고, 세가지의 방식으로 동작한다.
Preflight Request
브라우저가 본 요청을 보내기 전에 보내는 "예비 요청"을 preflight라고 한다. 본 요청을 보내기 전에 브라우저가 스스로 이 요청이 안전한지 확인하기 위함이다.
Simple Request
예비 요청을 보내지 않고 바로 서버에게 본 요청만 보내고, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.
전반적인 로직은 Preflight Request와 같고 예비 요청의 유무만 다르다.
Credentialed Request
인증된 요청을 사용하는 방법이다.
CORS 해결 방법
Access-Control-Allow-Origin 세팅
정석의 방법대로, 서버에서 해결해주는 방법이다. 서버가 요청을 받을 출처를 허용시켜 놓는 방법으로, Access-Control-Allow-Origin 헤더에 알맞은 값을 세팅해주는 것이다.
Proxy
프론트 단에서 웹팩과 webpack-dev-server를 사용하여 개발 환경을 구축하는데, 거기서 제공해주는 Proxy 기능을 사용해서 CORS 정책을 우회하는 방법이다.
