<div id="readability-page-1" class="page"><div>주니어 프론트엔드 개발자에게 CORS는 어려운 문제 중에 하나라고 생각한다. 
보안 관련된 어떤 이유때문에 에러를 낸다는것까진 알겠는데, 에러를 해결하는 방법이 막막하다.
풀스택 개발자로 개발자 커리어를 이어나가면서, 의외로 많은 개발자들이 (주니어 프론트엔드 개발자든, 아니든 상관없이) CORS에 대해 오해하고 있는 모습을 보았다. 또 CORS에러를 해결하는 많은 방법이 이미 존재하지만, 그것들을 잘 모르는 사람들이 많았다는걸 알게되었다.
CORS에 대해 사람들이 쉽게 할만한 오해 몇가지를 바로잡고, CORS로 인한 오류를 해결할 방법을 몇가지 제시해보겠다.
<h2 id="cors에-대한-몇가지-오해">CORS에 대한 몇가지 오해</h2>
프론트엔드 개발만 해본 웹개발자라면 해볼만한 CORS에 대한 오해가 몇가지 있다. 이것들을 풀고나서 해결법을 써보겠다.
<h3 id="오해-1-cors-에러는-서버가-보내는-에러다">오해 1: CORS 에러는 서버가 보내는 에러다.</h3>
CORS는 <a href="https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0">CSRF</a> 라고 불리는 브라우저 취약점 공격으로부터 브라우저 사용자를 보호하기 위해 만든 기능이다.
HTTP 표준 스펙에 포함되어 있고, CORS 관련 기능의 구현은 브라우저 개발사에게 책임이 있다. 웹 표준 기술을 따르는 정상적이고 일반적인 브라우저라면 CORS 역시 표준 스펙에 맡게 구현되어 있다.
<blockquote>
여기서 일반적인 브라우저 라 함은, 익스플로러를 제외한 크롬, 사파리, 파이어폭스, 오페라 등을 말한다. 즉, 평범한 일반 사용자가 손쉽게 다운로드 받아서 쓸수 있는 종류의 (IE 제외...) 브라우저들이다. 
크로미움 기반의 브라우저 중에서, 중요한 보안정책들을 의도적으로 비활성화시킨 버전의 특이한 브라우저들도 존재하는데, 이 경우 CORS 에러가 발생하지 않을 수도 있다. (단, 이건 CORS 에러에 대한 올바른 해결법은 아니다.)
</blockquote>
CORS 정책은 서버에 저장되어있으며, 저장된 CORS 정책을 브라우저에게 보내주는 일을 서버가 맡고 있긴 하다. 
하지만, 그 CORS정책을 보내달라고 서버에게 요청하는건 브라우저이다.
<ol>
<li>먼저, 브라우저에서 http요청이 발생하면 브라우저는 발생한 http요청이 CORS검증을 해야하는 상황인지 판단한다.</li>
<li>보안 정책상 검증이 필요한 상황에 해당하면 CORS 검증을 서버에 요청한다. (Preflight Request)</li>
<li>서버에게서 응답받은 CORS검증 요청 결과에 따라 브라우저는 발생했던 http요청을 취소시켜버리고 에러를 뱉는다.</li>
</ol>
즉, CORS 에러는 브라우저에서 발생한다.
<h3 id="오해-2-외부-공격으로부터-서버를-보호하기-위해-특정-도메인ip-이외의-경로로-들어오는-요청을-차단하는게-cors에러이다">오해 2: 외부 공격으로부터 서버를 보호하기 위해 특정 도메인/IP 이외의 경로로 들어오는 요청을 차단하는게 CORS에러이다.</h3>
CORS는 보안정책중 하나이지만, 보호의 대상은 서버가 아니다.
CORS는 HTTP 요청 헤더 중에서 <code>Origin</code> 이라는 헤더와 관련되어 있다.
브라우저에서 ajax 요청이 발생했을때, 현재 페이지의 주소창에 적힌 도메인과, ajax 요청 대상 url의 도메인이 같은 경우도 있지만, 다른 경우도 있다. 전자의 상황을 Same Origin Request (동일출처 요청) 이라고 부르며, 후자를 Cross Origin Request (교차출처 요청) 이라고 부른다.
브라우저에서 cross origin 요청이 발생했을때, 브라우저는 해당 요청에 <code>origin</code> 헤더를 자동으로 붙인다. 현재 페이지의 도메인이 Origin 헤더의 값이 된다.
<blockquote>
<code>http://www.abc.com/page/1</code> 페이지에서 <code>http://www.abc.com/api/products</code> 로 ajax 요청이 발생할 경우, 요청시 현재페이지와 요청 대상의 도메인이 같으므로 same origin request (동일출처요청) 이라고 할수 있다.
</blockquote>
<blockquote>
<code>http://www.abc.com/page/1</code> 페이지에서 <code>http://www.def.com/api/user</code> 으로 ajax 요청을 보낼경우, 요청시 현재페이지와 요청 대상의 도메인이 다르므로 cross origin request (교차출처요청) 이라고 할 수 있다. 
브라우저는 해당 요청의 헤더에 origin 헤더를 자동으로 추가하며, 그 값은 <code>http://www.abc.com</code> 이 된다.
</blockquote>
그런데 보통 서버에게 들어오는 요청들은 브라우저에서만 오는게 아니다. 서버끼리도 서로 요청을 한다.
브라우저를 통하지 않은 서버간 통신일 경우 Origin 헤더는 자동으로 붙는게 아니다. 그렇다고 못붙이냐 하면 그것도 아니다. 서버간 통신일때 요청자 서버는 원하면 Origin 헤더를 안 넣어도 되고, 넣고싶으면 Origin의 값으로 아무 문자열이나 마음대로 넣어서 보낼 수 있다.즉 서버간 요청 상황에서 CORS정책은 보안상 의미를 가지지 않는다.
<blockquote>
서버가 특정 요청자에게만 요청을 허용해야 할땐, 인증토큰이나 보안키 등 더 확실하고 간단한 방법을 사용하면 된다.
</blockquote>
<h3 id="오해-3-프론트엔드에서-ajax-요청-보낼때-어떤-특별한-라이브러리를-사용하거나-어떤-설정을-잘-해서-요청한다면-cors-문제를-해결할-수-있다">오해 3: 프론트엔드에서 AJAX 요청 보낼때 어떤 특별한 라이브러리를 사용하거나 어떤 설정을 잘 해서 요청한다면 CORS 문제를 해결할 수 있다.</h3>
만일 어떤 라이브러리나 설정을 통해, CORS 에러를 우회할 수 있는 방법이 있다면, 그건 브라우저 보안 취약점이다. 프론트엔드 소스코드만으로 CORS 에러를 우회하는 방법은 없어야 한다.
<blockquote>
만약 어떠한 프론트엔드 기술만으로 CORS 에러를 우회하는 방법을 발견했다면, 반드시 해당 브라우저를 개발한 기업 또는 오픈소스 커뮤니티에 알려주자. 취약점을 찾아줬다며 고마워할것이다.
</blockquote>
<h2 id="해결방법">해결방법</h2>
상황에따라 최선의 대처하는 방법이 다 다르다.
<h3 id="해당-api-개발자에게-요청하기">해당 API 개발자에게 요청하기</h3>
이 방법은
<ul>
<li>해당 API를 같은 회사/팀의 백엔드 개발자가 만든것일 때</li>
</ul>
그리고
<ul>
<li>이 API를 백엔드 개발자가 만든지 얼마 안돼서 이제 막 테스트 해보는 단계일때</li>
<li>또는, CORS 에러가 프로덕션 환경에서도 나는 것 같을때</li>
</ul>
가장 적합한 방법이다.
백엔드 막 세팅했을때 백엔드개발자가 실수로 CORS 관련 설정을 까먹을 때가 있다. ~~(나도 자주 그런다)~~
백엔드 개발자에게 현 상황을 말해주면 높은 확률로 ~~가스벨브 안 잠그고 집 나온 사람마냥 "아! 맞다"를 연발하며~~ 문제를 해결하고 있는 백엔드 개발자의 모습을 보게 될 것이다.
<h3 id="프론트엔드-개발서버-프록시-환경설정">프론트엔드 개발서버 프록시 환경설정</h3>
이 방법은
<ul>
<li>프론트엔드를 <code>create-react-app</code> 또는 <code>vue-cli</code> 와 같은 주요 라이브러리의 공식 프로젝트 세팅 툴을 통해 세팅했을 때</li>
<li>또, 프로덕션 환경에서는 cors 에러가 나지 않도록 백엔드 cors 설정이나 인프라 구성이 되어있어서, 로컬에서 개발할때만 cors 이슈가 있는상황일때</li>
</ul>
적합하다.
또, 리액트 한정으로 추가 조건이 더 있는데 (vue는 신경쓰지 않아도 된다.) 
cors 에러가 발생하는 api가, 내가 주로 쓰게 될 api 일때 여야 한다. 
(즉 여러가지 프론트엔드에서 외부 api 여러개를 섞어쓰는데, 다들 cors가 나는 상황은 아니어야 한다는 것)
<h4 id="create-react-app">create-react-app</h4>
공식문서: https://create-react-app.dev/docs/proxying-api-requests-in-development
package.json 에 다음과 같은 코드를 추가한다. 
테스트 하는동안 사용할 테스트용 api 서버의 도메인을 아래 코드의 <code>http://my-api-server.com</code> 라 써있는 부분에 대입해서 쓰자
<pre><code>"proxy": "http://my-api-server.com"</code></pre>
<h4 id="vue-cli">vue cli</h4>
공식문서: https://cli.vuejs.org/config/#devserver-proxy
vue.config.js 파일에 (만약 이 파일이 없다면, package.json 과 같은 경로에 만들자)
다음과같은 코드를 추가하자
<pre><code>module.exports = {
 devServer: {
 proxy: 'http://my-api-server.com'
 }
}</code></pre>
여러개의 api 서버에 대해 처리를 해줘야 한다면, 공식문서를 보면서 조금 더 설정을 커스텀 해주면 된다.
<h3 id="직접-proxy-서버-만들기">직접 proxy 서버 만들기</h3>
이 방법은 위의 방법들이 통하지 않을때 할 수 있는 최후의 방법이다. 
모든 상황에 대해 완벽하게 맞춤 대응이 가능하지만 치명적인 단점이 하나 있다. 
바로 당신이 백엔드를 만질 줄 알아야 한다는 것
글 윗쪽에서, 서버간 통신은 CORS의 영향을 안받는다고 써둔게 대목이 있었다. ~~(아무도 안읽었겠지만)~~
api 서버로부터 받아야 할 요청을 대신 요청해서 프론트엔드에 응답해주는 서버를 개발환경에 만들어두고, cors 정책을 내 맘대로 주무른 뒤, 개발과정동안 api요청을 거기로 보내면 된다.
<h2 id="하지-말아야-할-해결-방법들">하지 말아야 할 해결 방법들</h2>
<h3 id="백엔드에게-항상-허용으로-cors-정책-바꿔달라고-하기">백엔드에게, 항상 허용으로 CORS 정책 바꿔달라고 하기</h3>
프론트엔드의 머리를 쥐어뜯게 만들고 백엔드를 귀찮게 만드는 원흉인데도 모든 브라우저 벤더들이 열심히 이 명세를 만들고 관리하고 따르는 데에는 이유가 있다. 현관문 도어락 매번 여는게 귀찮다고 아무도 도어락을 뜯어두고 살진 않는다.
<h3 id="브라우저-보안기능이-비활성화된-커스텀-브라우저-사용해서-개발하기">브라우저 보안기능이 비활성화된 커스텀 브라우저 사용해서 개발하기</h3>
앞서 언급했던, CORS를 비활성화해둔 브라우저를 쓰는 방법 역시 좋은 대처법이 아니다.
브라우저에서 CORS를 비활성화 해서 프론트엔드에서 API를 붙이면, 나는 CORS 에러를 안겪겠지만, 일반적인 브라우저를 쓰는 사람들에겐, 다시 말해 나를 제외한 모든 사람들에겐 여전히 에러가 나고있는거다.
개발환경에서만 CORS 에러가 발생하고 있는거라고 확신할 수 있다면 모르겠지만, 스테이징/프로덕션 환경 테스트 할땐 CORS 문제가 나더라도 알아채기가 어려워지게 되고, 프로덕션 배포후 장애를 겪을 가능성이 생긴다.
<h2 id="하지만-저는-백엔드를-만질-줄-모르는데요">하지만 저는 백엔드를 만질 줄 모르는데요...</h2>
라고 생각하는 사람들이 있을것 같아서, nodeJS로 만든 간단한 프록시 서버를 직접 만들어봤다.
https://github.com/joonseokhu/api-proxy-server
급하게 만든거라 어떨진 모르겠지만, 한명에게라도 도움이 되었으면 한다.</div></div>

vraimentres.log

Joonseok Hu

주니어 프론트엔드 개발자에게 CORS는 어려운 문제 중에 하나라고 생각한다.
보안 관련된 어떤 이유때문에 에러를 낸다는것까진 알겠는데, 에러를 해결하는 방법이 막막하다.
풀스택 개발자로 개발자 커리어를 이어나가면서, 의외로 많은 개발자들이 (주니어 프론트엔드 개발자든, 아니든 상관없이) CORS에 대해 오해하고 있는 모습을 보았다. 또 CORS에러를 해결하는 많은 방법이 이미 존재하지만, 그것들을 잘 모르는 사람들이 많았다는걸 알게되었다.
CORS에 대해 사람들이 쉽게 할만한 오해 몇가지를 바로잡고, CORS로 인한 오류를 해결할 방법을 몇가지 제시해보겠다.
CORS에 대한 몇가지 오해
프론트엔드 개발만 해본 웹개발자라면 해볼만한 CORS에 대한 오해가 몇가지 있다. 이것들을 풀고나서 해결법을 써보겠다.
오해 1: CORS 에러는 서버가 보내는 에러다.
CORS는 CSRF 라고 불리는 브라우저 취약점 공격으로부터 브라우저 사용자를 보호하기 위해 만든 기능이다.
HTTP 표준 스펙에 포함되어 있고, CORS 관련 기능의 구현은 브라우저 개발사에게 책임이 있다. 웹 표준 기술을 따르는 정상적이고 일반적인 브라우저라면 CORS 역시 표준 스펙에 맡게 구현되어 있다.
여기서 일반적인 브라우저 라 함은, 익스플로러를 제외한 크롬, 사파리, 파이어폭스, 오페라 등을 말한다. 즉, 평범한 일반 사용자가 손쉽게 다운로드 받아서 쓸수 있는 종류의 (IE 제외...) 브라우저들이다.
크로미움 기반의 브라우저 중에서, 중요한 보안정책들을 의도적으로 비활성화시킨 버전의 특이한 브라우저들도 존재하는데, 이 경우 CORS 에러가 발생하지 않을 수도 있다. (단, 이건 CORS 에러에 대한 올바른 해결법은 아니다.)
CORS 정책은 서버에 저장되어있으며, 저장된 CORS 정책을 브라우저에게 보내주는 일을 서버가 맡고 있긴 하다.
하지만, 그 CORS정책을 보내달라고 서버에게 요청하는건 브라우저이다.
먼저, 브라우저에서 http요청이 발생하면 브라우저는 발생한 http요청이 CORS검증을 해야하는 상황인지 판단한다.
보안 정책상 검증이 필요한 상황에 해당하면 CORS 검증을 서버에 요청한다. (Preflight Request)
서버에게서 응답받은 CORS검증 요청 결과에 따라 브라우저는 발생했던 http요청을 취소시켜버리고 에러를 뱉는다.
즉, CORS 에러는 브라우저에서 발생한다. 
오해 2: 외부 공격으로부터 서버를 보호하기 위해 특정 도메인/IP 이외의 경로로 들어오는 요청을 차단하는게 CORS에러이다.
CORS는 보안정책중 하나이지만, 보호의 대상은 서버가 아니다.
CORS는 HTTP 요청 헤더 중에서 Origin 이라는 헤더와 관련되어 있다.
브라우저에서 ajax 요청이 발생했을때, 현재 페이지의 주소창에 적힌 도메인과, ajax 요청 대상 url의 도메인이 같은 경우도 있지만, 다른 경우도 있다. 전자의 상황을 Same Origin Request (동일출처 요청) 이라고 부르며, 후자를 Cross Origin Request (교차출처 요청) 이라고 부른다.
브라우저에서 cross origin 요청이 발생했을때, 브라우저는 해당 요청에 origin 헤더를 자동으로 붙인다. 현재 페이지의 도메인이 Origin 헤더의 값이 된다.
http://www.abc.com/page/1 페이지에서 http://www.abc.com/api/products 로 ajax 요청이 발생할 경우, 요청시 현재페이지와 요청 대상의 도메인이 같으므로 same origin request (동일출처요청) 이라고 할수 있다.
http://www.abc.com/page/1 페이지에서 http://www.def.com/api/user 으로 ajax 요청을 보낼경우, 요청시 현재페이지와 요청 대상의 도메인이 다르므로 cross origin request (교차출처요청) 이라고 할 수 있다.
브라우저는 해당 요청의 헤더에 origin 헤더를 자동으로 추가하며, 그 값은 http://www.abc.com 이 된다.
그런데 보통 서버에게 들어오는 요청들은 브라우저에서만 오는게 아니다. 서버끼리도 서로 요청을 한다.
브라우저를 통하지 않은 서버간 통신일 경우 Origin 헤더는 자동으로 붙는게 아니다. 그렇다고 못붙이냐 하면 그것도 아니다. 서버간 통신일때 요청자 서버는 원하면 Origin 헤더를 안 넣어도 되고, 넣고싶으면 Origin의 값으로 아무 문자열이나 마음대로 넣어서 보낼 수 있다.즉 서버간 요청 상황에서 CORS정책은 보안상 의미를 가지지 않는다.
서버가 특정 요청자에게만 요청을 허용해야 할땐, 인증토큰이나 보안키 등 더 확실하고 간단한 방법을 사용하면 된다.
오해 3: 프론트엔드에서 AJAX 요청 보낼때 어떤 특별한 라이브러리를 사용하거나 어떤 설정을 잘 해서 요청한다면 CORS 문제를 해결할 수 있다.
만일 어떤 라이브러리나 설정을 통해, CORS 에러를 우회할 수 있는 방법이 있다면, 그건 브라우저 보안 취약점이다. 프론트엔드 소스코드만으로 CORS 에러를 우회하는 방법은 없어야 한다.
만약 어떠한 프론트엔드 기술만으로 CORS 에러를 우회하는 방법을 발견했다면, 반드시 해당 브라우저를 개발한 기업 또는 오픈소스 커뮤니티에 알려주자. 취약점을 찾아줬다며 고마워할것이다.
해결방법
상황에따라 최선의 대처하는 방법이 다 다르다.
해당 API 개발자에게 요청하기
이 방법은
해당 API를 같은 회사/팀의 백엔드 개발자가 만든것일 때
그리고
이 API를 백엔드 개발자가 만든지 얼마 안돼서 이제 막 테스트 해보는 단계일때
또는, CORS 에러가 프로덕션 환경에서도 나는 것 같을때
가장 적합한 방법이다.
백엔드 막 세팅했을때 백엔드개발자가 실수로 CORS 관련 설정을 까먹을 때가 있다. (나도 자주 그런다)
백엔드 개발자에게 현 상황을 말해주면 높은 확률로 가스벨브 안 잠그고 집 나온 사람마냥 "아! 맞다"를 연발하며 문제를 해결하고 있는 백엔드 개발자의 모습을 보게 될 것이다.
프론트엔드 개발서버 프록시 환경설정
이 방법은
프론트엔드를 create-react-app 또는 vue-cli 와 같은 주요 라이브러리의 공식 프로젝트 세팅 툴을 통해 세팅했을 때
또, 프로덕션 환경에서는 cors 에러가 나지 않도록 백엔드 cors 설정이나 인프라 구성이 되어있어서, 로컬에서 개발할때만 cors 이슈가 있는상황일때
적합하다.
또, 리액트 한정으로 추가 조건이 더 있는데 (vue는 신경쓰지 않아도 된다.)
cors 에러가 발생하는 api가, 내가 주로 쓰게 될 api 일때 여야 한다.
(즉 여러가지 프론트엔드에서 외부 api 여러개를 섞어쓰는데, 다들 cors가 나는 상황은 아니어야 한다는 것)
create-react-app
공식문서: https://create-react-app.dev/docs/proxying-api-requests-in-development
package.json 에 다음과 같은 코드를 추가한다.
테스트 하는동안 사용할 테스트용 api 서버의 도메인을 아래 코드의 http://my-api-server.com 라 써있는 부분에 대입해서 쓰자
"proxy": "http://my-api-server.com"
vue cli
공식문서: https://cli.vuejs.org/config/#devserver-proxy
vue.config.js 파일에 (만약 이 파일이 없다면, package.json 과 같은 경로에 만들자)
다음과같은 코드를 추가하자
module.exports = {
  devServer: {
    proxy: 'http://my-api-server.com'
  }
}
여러개의 api 서버에 대해 처리를 해줘야 한다면, 공식문서를 보면서 조금 더 설정을 커스텀 해주면 된다.
직접 proxy 서버 만들기
이 방법은 위의 방법들이 통하지 않을때 할 수 있는 최후의 방법이다.
모든 상황에 대해 완벽하게 맞춤 대응이 가능하지만 치명적인 단점이 하나 있다.
바로 당신이 백엔드를 만질 줄 알아야 한다는 것
글 윗쪽에서, 서버간 통신은 CORS의 영향을 안받는다고 써둔게 대목이 있었다. (아무도 안읽었겠지만)
api 서버로부터 받아야 할 요청을 대신 요청해서 프론트엔드에 응답해주는 서버를 개발환경에 만들어두고, cors 정책을 내 맘대로 주무른 뒤, 개발과정동안 api요청을 거기로 보내면 된다.
하지 말아야 할 해결 방법들
백엔드에게, 항상 허용으로 CORS 정책 바꿔달라고 하기
프론트엔드의 머리를 쥐어뜯게 만들고 백엔드를 귀찮게 만드는 원흉인데도 모든 브라우저 벤더들이 열심히 이 명세를 만들고 관리하고 따르는 데에는 이유가 있다. 현관문 도어락 매번 여는게 귀찮다고 아무도 도어락을 뜯어두고 살진 않는다.
브라우저 보안기능이 비활성화된 커스텀 브라우저 사용해서 개발하기
앞서 언급했던, CORS를 비활성화해둔 브라우저를 쓰는 방법 역시 좋은 대처법이 아니다.
브라우저에서 CORS를 비활성화 해서 프론트엔드에서 API를 붙이면, 나는 CORS 에러를 안겪겠지만, 일반적인 브라우저를 쓰는 사람들에겐, 다시 말해 나를 제외한 모든 사람들에겐 여전히 에러가 나고있는거다.
개발환경에서만 CORS 에러가 발생하고 있는거라고 확신할 수 있다면 모르겠지만, 스테이징/프로덕션 환경 테스트 할땐 CORS 문제가 나더라도 알아채기가 어려워지게 되고, 프로덕션 배포후 장애를 겪을 가능성이 생긴다.
하지만 저는 백엔드를 만질 줄 모르는데요...
라고 생각하는 사람들이 있을것 같아서, nodeJS로 만든 간단한 프록시 서버를 직접 만들어봤다.
https://github.com/joonseokhu/api-proxy-server
급하게 만든거라 어떨진 모르겠지만, 한명에게라도 도움이 되었으면 한다.

CORS 😫

댓글