[Web] CORS

프로젝트를 하던중 CORS를 만나 삽질 했던 경험이 있다. 실수를 반복하지 않기 위해 CORS에 대해 정리 해보겠다.

 

CORS 왜 필요한가?

예시를 통해 알아보면,  착한닷컴이라는 사이트가 있고 내가 로그인해서 잘 쓰고 있다고 가정한다.

이 때, 로그인을 유지하기 위해 내 브라우저에 쿠키나, 토큰이 저장된다.

 

그런데 착한닷컴으로 나의 정보를 빼내기 위해  악당이 나쁜닷컴을 만들었다.

악당은 링크가 담긴 메일을 보내거나 피싱 사이트로 유인해서 나를 나쁜 닷컴으로 유인한다.

이 때, 내가 나쁜 닷컴에 접속 한다는 것은 악당이 만든 html,css,javascript등을 내 브라우저에 받는다는 뜻이다.

이 악당이 javascript코드로 내 브라우저에 있는 착한닷컴 토큰이나 쿠키를 보내 착한닷컴으로 부터 내 정보를 빼낼 수 있게 되는 문제가 발생한다.

 

이러한 문제를 방지하기 위해 어떤 사이트에서 다른 사이트로 요청이 못 가게끔 방지하는것이 SOP(동일 출처 정책)이다.

그리고 어떤 사이트에서 다른 사이트로 요청이 가도록 풀어주는것이 CORS(교차 출처 리소스 공유)이다. 

 

 

CORS란 무엇인가?

원래 서로 다른 출처끼리 요청을 주고 받는게 안되는게 디폴드였다. 그런데 웹 생태계가 다양해 지면서 여러 서비스들간에 보다 자유롭게 데이터가 주고받아질 필요가 생겼다. 그래서 이걸 합의된 출처들간에 합법적으로 허용해주기 위해 어떤 기준을 충족시키면 리소스 공유가 되도록 만들어진 매커니즘이 CORS이다.

 

심화 CORS

착한닷컴에서 네이버 지도 API로 요청을 보낸다고 가정한다. 이는 다른 출처로의 요청이니까 cross-origin 요청이다.

브라우저는 이처럼 다른 출처끼리의 요청이 보내질 때는 origin이라는 header를 추가한다.

이 header의 origin 항목에는 요청하는 쪽의 scheme, 도메인, 포트등이 담긴다.

이 요청을 받은 네이버는 응답 해더에 지정된 access-control-allow-origin 정보를 실어서 보낸다.

만약 착한닷컴을 네이버 지도 API 사용 설정에 넣었다면 착한닷컴도 여기에 포함된다.

브라우저가  origin에서 보낸 출처값이 서버의 답장 헤더에 담긴 access-control-allow-origin에 똑같이 있으면 안전한 요청으로 간주하고 응답 데이터를 받아오게 된다.

 

그리고 토큰등 사용자 식별 정보가 담긴 데이터에 대해서는 보다 엄격한데, 일단 보내는 쪽 옵션에서 credentials 항목을 true로 세팅해야 하고 받는 쪽에서도 access-control-allow-credentials을 true로 설정해야 한다.

 

그리고 CORS에서 요청들은 simple request, preflight 두 가지로 나눠 지는데 simple request는 요청을 다 보내긴 보내는데

통과를 못하면 답장을 못받는 거고, preflight는 요청을 보내는 것도 허락을 받는 것이다.