SOP(Same-Origin-Policy), CORS(Cross-Origin-Resource-Sharing)

자주 마주치는 CORS 오류

프론트엔드 프로젝트를 할 때 자주 마주치는 오류 중 하나로 CORS가 있다. 토이 프로젝트를 할 때 API를 가져가 쓸 때도 빈번하게 발생했고, 현업에서 백엔드/프론트엔드 서버를 다르게 구축하고 개발할 때도 마찬가지이다. 토이 프로젝트를 할 때는 한 줄 코드를 넣어 프록시를 우회하도록 하며 API를 쓰거나(a), webpack 설정 파일에 개발 시에 사용할 수 있게 proxy 설정(b)을 해주곤 했다. 좀 더 큰 규모의 프로젝트를 진행하면서는 백엔드 개발자에게 CORS 해결을 위해 협조를 요청해서 해결했다. (사전 지식이 부족했을 때 프론트엔드 단에서 실수인가 싶어서 온갖 자료를 찾아보면서 방법을 강구해봤지만 AWS 서버 설정 페이지에서 단 한 번의 클릭으로 해결할 수 있는 문제였다...)

// Case a:
const proxy = 'https://secret-ocean-49799.herokuapp.com/'
const some_api = `${proxy}https://api.example.com`;

fetch(some_api)
    .then(res => {
          return res.json();
        })
    .catch(err => {
          console.log(err)
    })

// Case b:
// webpack.config.js
// ..
devServer: {
      port: 4000,
      open: true,
      proxy: {
        '/': 'http://localhost'
      }
},
// ..

CORS가 필요한 이유

처음에는 CORS 오류가 굉장히 귀찮고 까다로웠는데, CORS가 왜 시작되었는지를 생각하면, 마냥 귀찮아할 만한 문제는 아니었다. CORS는 Cross-Origin-Resource-Sharing의 줄임말로 SOP(Same-origin-policy)를 예외적으로 허용하기 위해 생겨난 정책이다. 자바스크립트가 브라우저에 도입되면서 동적이고, 혁신적인 일이 가능해졌지만, 그만큼 보안상 위험도가 올라간 터라 그 즈음부터 같은 출처의 리소스하고만 상호작용한다는 룰이 추가되었다.

하지만, 위에 언급한 것처럼 서버를 다르게 구축하고 개발하기도 하는 등 같은 출처(Resource)가 아닌 경우에 소통해야 할 일이 생겼다. 이를 위한 정책이 CORS이다. 이때 '출처'란 프로토콜, 호스트, 포트가 같은 경우를 같은 출처라 말한다. cross-origin을 다른 출처로 이해하면 좋다.

CORS Requests

웹 브라우저 위에서 웹 애플리케이션이 다른 출처의 자원을 요청할 때 우리는 이를 cross origin requests라 부르며, CORS Preflighted Requests 그리고 simple requests 이렇게 크게 두 가지 종류로 나눠볼 수 있다.

CORS Preflighted Requests

pre 라는 접두어가 의미하는 것처럼, 미리 요청을 보내 앞으로 클라이언트가 서버에 HTTP 요청을 예정인데 이것이 가능한지 검토하는 요청이다. OPTION 메서드를 통해 보낸다.

Simple Requests

반면 단순 요청은 preflighted request를 생략한다. 대신 특정 HTTP Method, 특정 HTTP Header를 갖추고 있을 때만 가능한 요청이다.

https://foo.example의 웹 페이지에서 https://bar.other 출처의 리소스를 요청하고자 할 때를 살펴보자. 아래 같은 시나리오를 생각해볼 수 있다.

const xhr = new XMLHttpRequest();
const url = 'https://bar.other/resources/public-data/';

xhr.open('GET', url);
xhr.onreadystatechange = someHandler;
xhr.send();

클라이언트에서 필요한 자원을 가진 서버의 주소(https://bar.other/resources/public-data/)를 요청할 때(c), 서버는 아래처럼 CORS 헤더를 통해 응답할 것이다.(d)

// Case C :
GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example

// Case D:
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

이렇게 서버가 응답하면서 Access-Control-Allow-Origin 헤더를 보내주고 있는데, 값이 * 와일드 카드로 되어 있다. 리소스는 어떤 origin에서든 접근 가능하다는 표식이다. 편하지만, 모든 도메인에서 접근이 가능하다는 뜻이므로, 보안 상 취약하다.

보안을 조금 더 강화하면 아래처럼 작성할 수도 있다.

Access-Control-Allow-Origin: https://foo.example

이제 위 리소스로부터 오는 요청만 허용한다는 의미이다.

Reference

• 웹 보안 모델 이야기(SOP, CORS)
• 교차 출처 리소스 공유 (CORS)
• CORS 이젠 끝내보자