[ WIL ] ( Week 6 주차) 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)

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

 

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다.

교차 출처 요청의 예시: https://domain-a.com 프런트 엔드 JavaScript 코드가 XMLHttpRequest 사용하여 https://domain-b.com/data.json 요청하는 경우.

보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다. 예를 들어, XMLHttpRequestFetch API는 동일 출처 정책을 따름. 즉, 이 API를 사용하는 웹 애플리케이션은 자신의 출처와 동일한 리소스만 불러올 수 있으며, 다른 출처의 리소스 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해야 한다.

 

 

 

CORS 체제는 브라우저와 서버 간의 안전한 교차 출처 요청 및 데이터 전송을 지원합니다. 최신 브라우저는 XMLHttpRequest 또는 Fetch와 같은 API에서 CORS를 사용하여 교차 출처 HTTP 요청의 위험을 완화한다.

 

 

어떤 요청이 CORS를 사용할까?

교차 출처 리소스 공유 표준은 웹 브라우저에서 해당 정보를 읽는 것이 허용된 출처를 서버에서 설명할 수 있는 새로운 HTTP 헤더를 추가함으로써 동작한다. 추가적으로, 서버 데이터에 부수 효과(side effect)를 일으킬 수 있는 HTTP 요청 메서드(GET 제외한 HTTP 메서드)에 대해, CORS 명세는 브라우저가 요청 OPTIONS "프리플라이트"(preflight, 사전 전달)하여 지원하는 메서드를 요청하고, 서버의 "허가"에 떨어지면 실제 요청을 보내도록 요구하고 있다.

또한 서버는 클라이언트에게 요청에 "인증정보"(쿠키, HTTP 인증)를 함께 보내야 한다고 알려줄 수도 있다.

CORS 실패는 오류의 원인이지만, 보안상의 이유로 JavaScript에서는 오류의 상세 정보에 접근할 수 없으며, 알 수 있는 것은 오류 발생했다는 사실뿐이다. 정확히 어떤 것이 실패했는지 알아내려면 브라우저의 콘솔을 봐야 합니다.

이후 항목은 시나리오와 함께, 사용한 HTTP 헤더의 상세 내용을 다룬다.

 

출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

교차 출처 리소스 공유 (CORS) - HTTP | MDN

---

자주보는 얄코님의 강의에서 CORS에 대한 내용을 보아서, 내용을 다시 한번 정리해 보았다.

 

관련 URL : https://youtu.be/bW31 xiNB8 Nc? si=foepV_rofbW7 QO-y 

YOUTUBE 얄팍한 코딩 -  웹개발 짜증유발자! CORS가 뭔가요?

 

한 사이트에서 주소가 다른 서버로 요청을 보낼 때 자주 접하게 되는 오류 CORS

 

주소가 ‘어쩌고’ 닷컴에서 URL ‘저쩌고’ 닷컴 서비스에 API로 정보를 받아오기 위해서 프런트에서 HTTP요청을 보냈을 때 미리 어떤 설정을 해 주지 않으면 CORS문제로 막히게 된다. ( * postman과 같이 디른 걸로 요청하면 다되는데, 웹으로 하면 막힐 때가 많음 ). 

▶︎  웹사이트에서! 즉 브라우저인 프런트엔드에서 AJAX를 보낼 때마다 안됨 ( 크롬 / 에지 / 사파리 )

 

CORS는 왜 있는 걸까? 

예를 들어 착한 닷컴이라는 사이트가 있다고 가정하자.

어떤 사이트에 로그인하면, 다음에 접속할 때 로그인이 유지가 되어야 하는데 그것을 캐시라고 한다.

내 로그인정보를 토큰으로 저장해서,  로그인했던 사이트에 접속할 때마다 요청에 실어 보내면 그 사이트에서 이 쿠키를 확인하고 로그인을 확인할 수 있다.  만약 내가 크롬을 통해 로그인을 진행했다면, 크롬에 내 정보가 저장이 되어있다는 것이 된다.

이때, 이러한 정보를 빼내기 위해 나쁜 닷컴을 만들어 악성메일이 이나 댓글을 통해 해당 사이트로 유인하게 할 수 있다. 

나쁜 유저의 브라우저에 접속을 하면  Html / css / js 코드가 내 브라우저에 받아질 수 있다. 

그렇다면, 나의 착한 닷컴에 저장된 내 정보를 가지고  악의적인 행동을 취할 수 있게 된다. 

이뿐만 아니라 다른 API를 조작할 수 있기에 브라우저는 이를 방지한다.

 

CORS(Cross-Origin Resource Sharing) 다른 출처 간의 리소스를 주고받을 수 있음,

SOP (Same-Origin Policy) 동일 출처 정책 (요청을 막는 것)

 

원래 서로 다른 출처끼리 요청을 주고받는 것은 안 되는 게 기본값이었다.

하지만, 웹 생태계가 다양해지면서 여러 서비스들 간에 보다 자유롭게 데이터가 주고받아질 필요가 생기게 되었다.

그런데 다른 사이트 간의 요청을 브라우저가 막고 있어 개발자들은 jsonp (*현재는 거의 사용하지 않음) 우회해서 사용했다. 

이걸 합의해서 충족시키면 리소스가 공유되어 사용할 수 있을까 해서 만들어진 것이 CORS (교차 출처 자원 공유 방식)이다.

 

단, 조건이 있다.

요청을 받는 백엔드 쪽에서 허락할 다른 출처들을 미리 명시해 두면 된다.

백엔드 서버를 프로그래밍할 때 쓰는 프레임워크들을 살펴보면 CORS 옵션을 넣는 방법들이 쉽게 마련돼 있다. 여기다 허용할 사이트들을 적어주면 이제 거기서 지정한 사이트에서 이 서버로 얼마든지 HTTP요청을 보낼 수 있다.

아무나 보내도 되는 요청의 경우 일반적으로 별표, 와일드카드를 적어 넣으면 누구나 다 쓸 수 있다.

네이버 지도와 같은 api도, CORS를 허용해 주는 주소를 지정하는 페이지가 따로 있다.

 

 

여기서, header란, 데이터가 다른 곳으로 전송될 때 

데이터의 맨 앞쪽에 붙은 보충 정보라고 보면 된다.

받는 쪽의 IP주소 사용할 프로토콜이나 옵션 등이 담기는데  이는 우편으로 치자면 봉투에 적인 내용이라고 볼 수 있다. (Header에는 요청하는 쪽의 schema 도메인, 그리고 포트가 담긴다. )

 

origin에서 보낸 출처값이 서버에 답장 헤더에 담긴 Access-control-allow-Origin에 똑같이 있으면 안전한 데이터로 간주하고 응답을 받아오게 된다.

 

토큰등 사용자 식별 정보가 담긴 요청은, 보다 엄격하다. 보내는 측 요청의 옵션에 credentials 항목을 true로 세팅해야 하고, 

받는 쪽에서도 아무 출처나 다 된다는 와일드카드가 아니라, 보내는 쪽의 출처 웹페이지 주소를 정확히 명시한 다음  Access-control-allow-credentials 항목을 true로 맞춰줘야 한다. ( 브라우저에 저장된 쿠키가 나쁘게 쓰일 수 있어서 보다 조건을 높게 갖추어야 함 )

 

▶︎  Simple request 방식으로 get / post 등 일정조건의 요청에 사용됨

▶︎  Put / delete 등은 preflight 요청을 먼저 보내서 본 요청이 안전한지 확인하고 여기서 허락이 떨어져야 요청을 보낼 수 있다. ( 서버에 영향을 줄 수 있는 요청으로 먼저 허용여부 검증이 필요함 ) 

---

 

 

첨부 URL : https://evan-moon.github.i/2020/05/21/about-cors/

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

 

프로젝트 진행시 프론트와 연결하면서 위와같은 오류가 발생되었다.

 

---

 

 

 

 

 

 

Wil을 적기 위해서 CORS를 찾아보면서, 대부분의 제목들이 웃프지만 저러했다.

실제로 팀원들과 프로젝트를 하면서 첨부 이미지와 같이 CORS오류가 나는 것을 보기도 했다.

(트러블 슈팅에서 가져옴!)

협업을 하다 보면 심심치 않게 마주하겠지. 

다음 주도 파이팅 해야지! ㅇ ㅏ자!