프로젝트를 하고나서 부족하다고 생각했던 cors에 대해 정리해보자 ~^^ (망할 이거 정리 안하니까 헤깔려서 해야겠다.)
What is CORS?
Cors는 서버가 브라우저 리소스 로드를 허용해야 하는 원본이 아닌 다른 모든 원본을 표시할 수 있는 HTTP 헤더 기반 메커니즘이다. 즉, 서로 다른 오리진에서 리소스를 공유할 경우 적용되는 정책이다.
여기에서 오리진은 domain, scheme 또는 port를 의미한다.
Functional overview
교차 출처 리소스 공유 표준은 웹 브라우저에서 해당 정보를 읽는 것이 허용된 출처를 서버에서 설명할 수 있는 새로운 HTTP 헤더를 추가함으로써 동작합니다. 추가적으로, 서버 데이터에 부수 효과(side effect)를 일으킬 수 있는 HTTP 요청 메서드(GET을 제외한 HTTP 메서드)에 대해, CORS 명세는 브라우저가 요청을 OPTIONS 메서드로 "preflight"(사전 전달)하여 지원하는 메서드를 요청하고, 서버의 "허가"가 떨어지면 실제 요청을 보내도록 요구하고 있습니다. 또한 서버는 클라이언트에게 요청에 "인증정보"(쿠키, HTTP 인증)를 함께 보내야 한다고 알려줄 수도 있습니다.
Examples of access control scenarios
MDN에 보면 3가지 시나리오가 소개된다.
- simple request
- Preflight requests
- Requests with credentials
1. simple request
단순 요청의 경우에는 cors preflight가 일어나지 않는데 다음과 같은 경우에 일어난다.
- 요청의 메소드는 GET, HEAD, POST 중 하나여야 한다.
- Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
- 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.
2. Preflight requests
가장 일반적으로 웹브라우저를 개발할 때 가장 많이 볼 수 있는 경우이다. OPTION 매서드를 사용한 예비요청과 본요청으로 나누어서 요청이 가게 된다.
이때 브라우저가 본 요청을 보내기 전에 보내는 예비 요청을 Preflight라고 부른다. 이 예비 요청에는 HTTP 메소드 중 OPTIONS 메소드가 사용된다. 예비 요청의 역할은 본 요청을 보내기 전에 브라우저 스스로 이 요청을 보내는 것이 안전한지 확인하는 것이다.
실제로 network 창에서 확인하게 되면 option 요청이 먼저 가는 것을 확인할 수 있고 응답 헤더를 확인 할 수 있게 되는데 여기에서 "Access-Control-Allow-Origin" 값이 중요하다. Access-Control-Allow-Origin은 리소스에서 접근가능한 도메인인지 알려준다.
