CORS 너는 누구인가

웹 개발을 하다보면 마주칠 수 밖에 없는 CORS 에러
안겪어본 개발자는 없을거다.

오늘은 CORS 에러가 뭐고 왜 등장하게 되었는지 그리고 해결방법까지 알아볼 예정이다.

 

CORS란 무엇인가?

CORS를 풀어서 쓰면 Cross-Orgin Resource Sharing
말 그대로 Origin 리소스를 공유했기 때문에 오류를 발생했다는 뜻이다.

아니 그러면 Orgin은 뭐냐

 

출처 (Origin)

우리가 서버에 요청을 보낼때 URL 형태로 요청을 한다.
그 URL은 아래와 같은 형태로 이루어진다.

https://share.google/lZ9gv7HJhJsk3Ziyb

여기서 Origin은 Protocol + Host + Port 이다.

 

이런식으로 개발자도구 콘솔에서도 현재 origin을 확인할 수 있다.
웹 사이트에서는 Protocol과 Host만 나오지만

로컬 서버에서는 이렇게 포트까지 나오는 것을 알 수 있다.

 

그래서 CORS가 뭔데?

CORS 정책은 Same-Origin Policy(동일 출처 정책)을 기반으로 하는 정책이다.

SOP(Same-Origin Policy)는 2011년 RFC 6454라는
웹 출처 개념(The Web Origin Concept)을 정의한 표준문서에서 처음 등장한 정책이다.

SOP는 브라우저가 서로 다른 출처에서 가져온 리소스(스크립트, 쿠키 등)을 상호작용하지 못도하록 격리하는 정책이다.

https://share.google/qUUTsiQk9vdSYXaRH

아니 근데 왜 못하도록 하는거지?

 

동일 출처 정책은 왜 필요한가?

우리보다 똑똑한 분들이 만든 정책이니 이유가 다 있겠지만 그래도 한번 알아보자보안 관련 정책이기 때문에 보안과 관련되어있다.만약 출처가 다른 두 어플리케이션이 자유롭게 리소스를 주고 받을 수 있다면
CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법으로
우리가 만든 어플리케이션에서 해커가 개인정보를 훔쳐갈 수 있다.

https://share.google/TBM04TxR71rdq0Vb2

너무 오랜만에 봐서 헷갈리시는 당신을 위해 CSRF와 XSS에 대해 살짝 설명해보겠다.

 

CSRF와 XSS

CSRF (Cross-Site Request Forgery, 교차 사이트 요청 위조)

CSRF는 사용자가 자신의 의지와는 상관 없이
이미 로그인된 웹사이트에서 특정 동작을 실행하도록 만드는 보안 취약점이다.

공격자가 사용자의 브라우저가 특정 사이트에 대해 가진
인증 정보(쿠키)를 가로채서 로그인을 하거나 상호작용을 하는 것이다.

그러면 서버는 공격자가 훔친 인증정보를 보고
사용자가 직접 요청한 것으로 착각하여 요청을 처리하게되는 것이다.

 

XSS (Cross-Site Scripting, 교차 사이트 스크립팅)

XSS는 공격자가 웹사이트에 악성 스크립트를 삽입하여,
해당 사이트에 방문하는 사용자의 브라우저에서 악성 스크립트가 실행되게 하는 공격이다.

XSS 공격을 당하면 세션/쿠키 정보가 탈취되거나
가짜 로그인 폼을 띄워 사용자의 비밀번호를 훔쳐가거나
사용자 몰래 특정버튼을 클릭하게 하거나 악성 사이트로 리다이렉트 시킬 수 있다.

간단하게 CSRF와 XSS의 차이에 대해 알아보자면

CSRF는 사용자의 브라우저를 통해 서버를 공격하는 것이라면
XSS는 사용자의 브라우저에서 사용자를 공격하는 것이다.

---

 

자. 다시 돌아와서
이런 보안 취약점이 발생할 수 있기 때문에 SOP 정책이 필요한 것이다.

 

하지만 웹에서는 다른 출처에 있는 리소스를 사용해야 하는 일이 많기 때문에
무작정 SOP를 지킬 수도 없는 노릇이다.

뭐 예를 들어 외부 이미지를 사용해야 한다거나

외부 API (지도나 OAuth 로그인 같은..)를 사용해야 한다거나 등

몹시 많은 예시가 있다.

 

그래서 SOP는 기본 보안 정책으로 유지하되
특정 상황에서는 추가 검증을 통해 조건부로 접근을 통과시키도록 하였다.

그 중 하나가 바로 CORS 정책이다.

 

교차 출처 리소스 공유 (Cross-Origin Resource Sharing)

CORS는 다른 출처의 리소스 공유에 대한 허용, 비허용에 대한 정책인 것이다.

CORS 정책은 기본적으로 브라우저에 구현된 정책으로
서버가 응답을 한다고 해도 브라우저가 CORS 정책 위반이라고 판단하면 해당 응답은 사용하지 않는 것이다.

https://evan-moon.github.io/2020/05/21/about-cors/

아니 그러면 어떻게 CORS 정책을 판단하나?

 

1. 클라이언트에서 HTTP 요청 헤더에 Origin을 담아서 전달한다

아래는 naver에서 요청하는 API 중 하나를 예시로 들겠다.

 

2. 서버는 응답 헤더에 Access-Control-Allow-Origin을 담아서 클라이언트에 전달한다.

여기서 Access-Control-Allow-Origin은
이 리소스를 접근하는 것을 허용한다는 출처 URL이다.

 

3. 클라이언트(브라우저)에서 Origin과 서버의 Access-Control-Allow-Origin을 비교한다.

만약 유효하지 않다면 해당 응답을 사용하지 않고 버린다. CORS 에러가 발생한다는 것이다.

예시에서는 둘다 https://shopsqurare.naver.com으로 동일하므로
오류가 발생하지 않는다.

 

CORS 에러 해결을 위해서는 서버의 허용이 필요하다.

결국 CORS 에러 해결을 위해서는 서버에서 응답을 보낼 때
헤더의  Access-Control-Allow-Origin 을 세팅해줘야 한다는 것이다.

 

하지만 보통 웹 개발자가 CORS에 마주치는 상황은 로컬에서 프론트엔드 개발할 때 일 것이다.
이 경우 백엔드에 Access-Control-Allow-Origin 을 세팅해 준다고 하더라도

http://localhost:port 같은 URL을 추가해 주는 경우는 드물다.
그렇기 때문에 필요한 것인 proxy 서버이다.

이 내용은 나도 nginx에 대해 공부하면서 다룬적이 있다.

Nginx란 무엇인가?

 

nginx 같은 proxy 서버 프로그램을 사용하지 않아도

프론트엔드 개발자가 많이 사용하는 라이브러리인
Webpack과 webpack-dev-server 같은 라이브러리를 사용해도
간단하게 프록시 기능을 사용할 수 있다고 하니 참고하면 좋을 것 같다.

 

CORS 작동 방식 3가지 시나리오

아까 간단하게 CORS가 어떻게 동작하는지에 대해 알아봤었다.

하지만 방금 알아본 것은 CORS 동작 흐름 이해를 위한 기본적인 동작이고
실제로는 CORS가 동작하는 방식은 세 가지의 시나리오 따라 변경된다.

예비 요청 (PreFlight Request)
가장 일반적인 방식으로, 브라우저가 본 요청을 보내기 전 안전한지 확인하기 위해 예비 요청을 먼저 보내는 시나리오이다.

단순 요청 (Simple Request)
예비 요청 없이 본 요청을 즉시 서버로 보내는 방식이다.

인증된 요청 (Credentialed Request)
클라이언트가 쿠키나 인증 헤더(Authorization) 등 자격 인증 정보를 포함해 요청할 때 발생하는 방식이다.

 

요런 시나리오가 있지만
자세한 것은 다음에 자세히 알아보도록하자....

 

 

참고한 사이트

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

🌐 악명 높은 CORS 개념 & 해결법 - 정리 끝판왕 👏

https://evan-moon.github.io/2020/05/21/about-cors/

CORS는 왜 이렇게 우리를 힘들게 하는걸까?

https://chuckchoiboi.github.io/cors-tutorial/

CORS Tutorial