프론트엔드 CORS 개념 정리

https://www.youtube.com/watch?v=bW31xiNB8Nc&ab_channel=%EC%96%84%ED%8C%8D%ED%95%9C%EC%BD%94%EB%94%A9%EC%82%AC%EC%A0%84 

얄박한 코딩사전 채널을 토대로 정리

 

 

 

 

프론트 개발을 하던 중 만들고 있는 웹사이트에서 외부 API에서 정보를 받아 오려고 할때 주로 발생한다.

즉, 한 사이트에서 주소가 다른 서버로 요청을 보낼 때 발생

 

Postman이나 다른 익스텐션 어플로 테스트를 하면 이상이 없지만 웹사이트(브라우저)에서의 요청에서는 CORS 에러가 나온다.

 

해당 하는 서버에서 요청을 막는 것이 아니라 브라우저(크롬) 쪽에서 연결을 막는 것이다.

주로 브라우저에서 접속하는 사이트 들은 당연하게도 되부 사이트여서 의심을 하는것이다.

즉, 브라우저는 사용자가 방문한 사이트에 대해 믿지 못해서 발생한다.

 

 

그럼 CORS가 있는 이유는 ?

주로 브라우저에서 사이트를 이용할 때 나의 브라우저의 쿠키로 사용자의 정보가 있다(토큰이나 세션 정보)

이러한 상황에서 악성사이트에 방문할 경우 자바스크립트 코드를 사용해서 사용자의 토큰이나 세션을 뽑아서 악용할 수 있다.

 

참고로 막는 것은 CORS(Cross-Origin-Resource-Sharing)가 아니라 SOP(Sam-Origin-Policy) 이다.

 

즉 CORS관련 에러는 CORS를 허용해줘라 라는 의미이다. (다른 출처간의 리소스를 공유 할 수 있게)

 

원래는 서로다른 출처간의 리소스 공유는 금지 되어있었다.

하지만 웹생태계가 커지다 보니 서로 다른 리소스간의 정보 공유가 필요해졌고 그로 인해서 생긴 기능이 CROS이다.

 

 

CORS를 위한 조건
요청을 받는 백엔드쪽에서 요청을 허락할 다른 출처들을 미리 명시해주는 것이다.

 

 

또한 브라우저는 다른 출처끼리의 요청이보낼 때는 Origin이라는 Header를 추가한다.

(헤더에는 주로 받는 쪽의 ip 주소, 사용할 프로토콜이나 옵션등이 담긴다)

 

Origin 에는 요청하는 쪽의 scheme과 도메인, 포트가 담긴다.

scheme : 요청할 자원에 접근할 방법   ex) http,ftp,telent

 

 

그리고 요청을 받은 서버는 응답에 지정된 Access-Contorl-Allow-Origin 정보를 실어서 보낸다.

즉 , 허락한 클라이언트의 url 정보를 담은 응답을 보낸다.

 

그러면 브라우저가 Origin에 있는 url(프론트)과 Access-Contorl-Allow-Origin에 있는 url(서버)과 비교해서 오케이 해준다.

즉, Origin에 담긴 출처값(프론트)이 (서버)의 답장 헤더에  담긴 Access-Contorl-Allow-Origin에  똑같이 있으면

      안정한 요청으로 간주하고, 응답 데이터를 받아오게 되는 것이다.

 

 

 

세션과 토큰이 담긴 요청 같은 경우에는 더욱 엄격하다.

보내는 측(클라이언트)에서는 요청의 옵션에 Credentials 항목을 true로 세팅해야 하고 받는 쪽(서버)에서도

아무 출처나 다 된다는 와일드카드(*)가 아니라 보낸쪽의 출처-웹페이지 주소를 정확히 명시한 다음

Access-Contorl-Allow-Credentials 항목을 true로 맞춰 줘야한다.

즉, 클라이언트와 서버 둘다 빡세게 점검을 한다.

 

위의 예제 설명은 get이나 post같은 simple request에 대항 한 설명이고

put이나 delete는 요청을 보내기 전에 preflight 요청이란걸 먼저 보내서 본 요청이 안정한지 확인한다.