📋 CORS (교차 출처 리소스 공유) 란?
웹 개발자라면 한번쯤 이러한 에러를 마주쳐봤을 것이다.
🚨 Access to fetch at ‘https://cors.api.com’ from origin ‘http://localhost:3000’ 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에 대해 알아보기 전, 출처와 SOP라는 것에 대해 먼저 알아보자.
📌 1. 동일 출처
출처 : https://beomy.github.io/tech/browser/cors/
평소 우리가 접근하는 URL의 구조를 나타내는 사진이다.
위 사진에서 Protocol + Host + Port 총 3가지가 같으면 동일 출처 (Same Origin)라고 한다.
📌 2. SOP (Same Origin Policy)
위에서 동일 출처에대해 알아봤다.
이번에 알아볼 SOP는 다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식이다.
다른 출처의 리소스를 사용하는 것을 왜 제한하는걸까?
다른 출처 요청의 위험성을 알아보기 위해 한가지 예시를 준비했다.
클라이언트가 인스타그램 사용 중 해커의 스크립트가 심어진 http://hacking.com URL을 눌러 페이지를 열었다. 해커의 페이지에는 클라이언트의 토큰을 사용해 개인정보를 탈취하는 스크립트가 심어져있었고 클라이언트의 개인정보는 그대로 해커에게 넘어갔다.
인스타그램 서버가 토큰만으로 유저를 판단한다면 클라이언트와 해커의 요청을 구분하기 힘들 것이다.
하지만 출처를 확인한다면 클라이언트와 해커의 출처는 서로 다르기 때문에 요청의 의도를 파악하고 해커의 요청을 차단할 수 있다.
이처럼 요청의 출처가 다르다면 SOP (동일 출처 정책, Same-Origin Policy)에 위반이라고 한다.
하지만 외부 라이브러리도 사용해야 하는데 요청과 리소스를 매번 동일한 출처로만 받을 수는 없다.
이 때 필요한 것이 CORS이다.
📌 3. CORS (Cross-Origin Resource Sharing)
이제 글의 본 목적인 CORS에 대해 알아보자.
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. - MDN
제목에도 적어놨듯이 CORS는 Cross-Origin Resource Sharing, 즉 교차(다른) 출처 리소스 공유이다.
쉽게 말하자면 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다.
아무리 보안이 중요하지만, 개발을 하다 보면 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야 하는 케이스도 있으며, 또한 실무적으로 다른 회사의 서버 API를 이용해야 하는 상황도 존재한다.
따라서 위와 같은 예외 사항을 두기 위해 CORS 정책을 허용하는 리소스에 한해 다른 출처라도 받아들인다는 것이다.
결국 우리를 괴롭히던 붉은 에러 메세지는 사실 브라우저의 SOP 정책에 따라 다른 출처의 리소스를 차단하면서 발생된 에러이며, CORS는 다른 출처의 리소스를 얻기위한 해결 방안이였던 것이다.
요약하자면 SOP 정책을 위반해도 CORS 정책에 따르면 다른 출처의 리소스라도 허용한다는 뜻이다.
그렇다면 어떻게 CORS 정책을 따르게 하여 SOP 정책을 회피할 수 있을까?
이를 알기 위해선 브라우저의 CORS 동작 과정을 먼저 알아야한다.
📌 4. 브라우저의 CORS 기본 동작
4-1. 클라이언트 HTTP 요청
기본적으로 웹은 HTTP 프로토콜을 이용하여 서버에 요청을 보내게 되는데,
이때 브라우저는 요청 헤더에 Origin 이라는 필드에 출처를 함께 담아 보내게 된다.
4-2. Server 응답
서버에서 해당 요청에 대한 응답 시 응답 헤더에 Access-Control-Allow-Origin 정보를 담아 보낸다.
4-3. 비교
요청할 때 보낸 Origin 정보와 서버에서 보낸 Access-Control-Allow-Origin 정보를 비교해 서버에서 보내준 Access-Control-Allow-Origin을 차단할지 말지 클라이언트 단에서 정한다.
유효하지 않다면 해당 응답은 버린다.
📌 5. CORS의 해결책
CORS 이슈는 외부 API 서버에서 데이터를 가지고 올 때 헤더에 접근을 허락하는 내용이 없으면 발생한다.
즉, 백엔드 개발자가 해결할 수 있는 부분인 것이다.
5-1. 크롬 확장 프로그램 설치하기 (로컬)
단순히 로컬 환경에서 API 요청 시의 CORS 이슈를 해결하고 싶다면, 굳이 백엔드까지 가지 않아도 크롬 확장 프로그램인 Allow CORS: Access-Control-Allow-Origin을 설치하면 해결된다.
5-2. 응답 헤더에 Access-Control-Allow-Origin 설정
로컬에서 뿐만 아니라 서버에서부터 근본적인 해결을 하고 싶다면 Access-Control-Allow-Origin를 설정해주면 된다.
5-3. 서버에서 외부 API 접근하기
CORS는 브라우저 보안 정책이므로 서버에서 서버로 요청 시 CORS 이슈가 발생하지 않는다.
5-4. Proxy 서버
서버와 서버 간 요청은 CORS 이슈가 발생하지 않는다는 것을 이용한 방식이다.
클라이언트에서 다이렉트로 서버로 요청 시 CORS 이슈가 발생하므로 중간에 Proxy 서버를 두어 해당 이슈가 발생하지 않도록 하는 방법이다.
