0. Intro
- 웹 페이지가 외부 서버와 통신할 때 발생하는 CORS 에러는 무엇이고 어떻게 해결할 수 있을까?
1. CORS vs SOP
(1) CORS (Cross Origin Resource Sharing)
- 한 출처(도메인, 프로토콜, 포트)에서 실행 중인 웹 사이트가 다른 출처의 리소스에
접근할 수 있도록권한을 요청하는 매커니즘 - 브라우저는 리소스가 자신의 출처와 다를 때 요청에
origin이라는 헤더를 추가해 교차 출처 HTTP(리소스) 요청을 실행한다.
(2) SOP (Same Origin Policy)
-
어떤 출처에서 불러온 스크립트가 다른 출처에서 가져온 리소스와
상호작용하는 것을 제한하는 것 -
리소스를 요청하고 무분별하게 제공 받는 것은 보안 상 취약하므로 브라우저는 기본적으로 SOP를 따른다.
-
동일한 출처 (
도메인,프로토콜,포트)에서 요청한 리소스 요청만을 허용한다.
즉,
CORS 에러는 SOP에 의해 서버가 CORS 요청을 거부할 때 발생하는 에러를 의미한다.
2. CORS 동작 방식
(1) Preflight Request
-
브라우저가 예비 요청과 본 요청으로 HTTP 요청을 나누어 서버에 전송하는 방식
-
예비 요청에서 HTTP 메서드
OPTIONS를 통해 요청을 보낸다. -
예비 요청은 본 요청을 보내기 전에 서버에 CORS를 허용 하는지(실제 요청을 보내기에 안전한지) 확인하는 역할을 하게된다.
-
서버는 200번 대의 성공 코드를 반환한다.
- OPTIONS 메서드
서버에서 추가 정보를 판별하는데 사용하는 메서드로 리소스를 변경하는데 사용할 수 없다.
- OPTIONS 메서드
(2) Simple Request
-
예비 요청을 하지 않고 바로 본 요청을 수행하는 방식
-
Simple Reqeust는 다음의 제약사항을 갖는다.
-
요청 메서드는
GET|HEAD|POST만을 사용한다. -
헤더는
Accept|Accept-Language|Content-Language|Content-Type|Cotent-Type|DPR|Downlink|Save-Data|Viewport-Width|Width만을 사용한다. -
헤더가
Content-Type일 경우application/x-www-form-urlencoded|multipart/form-data|text/plain의 값만을 허용한다.
-
(3) Credentialed Request
-
origin에서 보낸 출처 값이 서버의 답장 헤더에 담긴 Access-Control-Allow-Origin 정보가 동일하게 존재하면 안전한 요청으로 간주하고 응답데이터를 받아오게 된다.
-
Access-Control-Allow-Origin 값은 별표, 와일드 카드 방식이 아닌 구체적인 도메인이 필요하다.
-
Access-Control-Allow-Credentials 항목을 true로 설정 해야한다.
3. CORS ERROR 해결 방법
(1) Webpack DevServer Proxy 구축
- Webpack이 제공하는 Proxy를 통해 서버에 직접적으로 요청하지 않고 우회하여
CORS ERROR를 회피할 수 있다.
(2) Access-Control-Allow-Origin 설정
-
서버에서 응답 헤더에 올바른 Access-Control-Allow-Origin의 값을 주어 허용할 도메인을 설정한다.
가장 근본적인 해결 방법
4. 결론
- 브라우저는 보안 상의 문제로 SOP를 따르기 때문에
1. 프록시 서버 우회또는2. 백엔드의 응답 헤더 설정을 통해CORS ERROR를 해결할 수 있다.
