CORS 에러가 발생하는 이유

CORS 에러 만나보기

우선 CORS 에러를 만나보자. 개발자 툴을 열고 콘솔탭에서 아래 코드를 입력해보자.

fetch('https://www.google.com/');

크롬에서는 아래와 같은 에러메세지를 마주할 수 있다. (브라우저마다 에러메세지가 조금씩 다르게 뜰 수 있다.)

Access to fetch at 'https://www.google.com/' from origin 'https://actually-i-am.tistory.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

CORS 정책에 의해 구글로 접근이 차단되었다고 한다. (파파고로 번역했다)

CORS때문에 우리는 이 블로그에서 구글에 응답을 받지 못하는 것일까? CORS는 Cross-origin resource Sharing의 약자이다. 한국어로 다른 출처 리소스 공유라고 한다. 뜻만 들었을 땐 공유해줄 것 같은데 공유가 안 된다. 진짜로 다른 출처간 리소스를 공유하지 못하는 이유는 SOP때문이다.

SOP는 무엇인가

Same Origin Policy의 약자이다. 동일 출처 정책이라고 한다. 브라우저에서 다른 출처의 리소스를 사용하지 못하도록 제한하는 보안 방식이다. 출처란? URL에서 프로토콜, 호스트, 포트이다. 이 블로그(https://actually-i-am.tistory.com)와%EC%99%80) 구글(https://www.google.com/) 그래서 다른 출처다.

왜 이런 정책이 있는거냐면, 악의적인 사용자가 다른 사이트의 정보를 탈취하는 것을 막기 위해서다. 앞서 말했듯이 보안을 위함이다. 하지만 요즘 웹 사이트는 다른 사이트간에도 리소스를 공유할 일이 많다. 서로 다른 출처의 리소스가 필요하기에 나온 체제가 CORS란 것이다.

CORS가 일하는 방식

CORS의 자세한 정보는 https://developer.mozilla.org/ko/docs/Web/HTTP/CORS 이 페이지에서 확인할 수 있다.

간단히 말하자면 서버에서 허용한 출처에서는 서버의 리소스에 접근을 할 수 있다는 말이다. 그 일이 어떤식으로 일어나는지 우리가 처음 개발자 툴로 CORS에러를 만난 과정을 되짚어보자.

1. 브라우저는 origin(출처)을 첨부해서 서버에 요청을 보냈다.
2. 서버는 자신이 접근을 허가한 출처정보를 브라우저에 보냈다.
3. 브라우저에서 요청을 보낸 출처와 서버에서 허용한 출처를 확인한다.
4. 비교한 출처가 서로 다르므로 COR에러가 발생한다.

(Simple Requests인지 Preflight인지 혹은 그 외인지에 따라서 동작이 다르긴 하다.)

CORS 에러를 해결하는 방법

SOP와 CORS가 일하는 방식을 알면 CORS 에러를 해결하는 방법을 알 수 있다.

1. 클라이언트에서 요청하는 origin이 서버에서 허용하는 origin에 포함이 되면 된다.
   • 서버에서 해결 : Access-Control-Allow-Origin에 우리 클라이언트에서 보낼 오리진을 포함하기
   • 클라이언트에서 해결 : 프록시 서버 설정하기
2. SOP 정책에 걸리지 않는 방법을 사용한다.
   • 클라리언트에서 해결 : JSONP 사용하기 (GET요청만 가능)