CORS (Cross Origin Resource Sharing)

브라우저에서 웹 페이지가 다른 출처(Origin)로부터 리소스를 요청할 때 발생하는 보안 정책입니다.
출처 간 요청의 제어 및 보안을 강화하는 것입니다.

탄생 배경

• 사용자가 서비스에 로그인을 하면 다음에 접속하였을때 다시 로그인할 필요가 없도록 로그인이 유지되고 있는 경우가 많다.

• 브라우저에 토큰 등의 정보가 쿠키로 저장이 되어 있어서 브라우저에서 요청을 보낼때마다 쿠키를 실어 보낸다.

• 즉, API 요청마다 보내어지는 쿠키는 사용자의 인증정보!

• 사용자가 악의적인 사이트에 접속하게 되면 악의적인 사이트의 자바 스크립트가 사용자의 브라우저에 들어오게 된다.

• 해당 자바스크립트 코드에는 서비스에 개인정보를 요청하는 코드가 있을 수 있고 이에 사용자의 인증정보를 실어보낸 후 개인정보를 빼올 수 있다.

• 따라서 이러한 것들을 방지하기 위해서 브라우저는 다른 출처의 요청을 SOP(Same Origin Policy)를 통해서 막고있다.
  참고) SOP (Same Origin Policy)는 브라우저 보안 정책 중 하나로, 웹 페이지가 하나의 출처에서 불러온 스크립트가 다른 출처의 리소스에 접근하는 것을 제한합니다. CORS는 이 정책을 우회하거나 완화하는 메커니즘을 제공합니다.

• CORS는 이를 풀어주는 정책이다.

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

상황 예시

주소가 www.A.com, www.B.com 인 웹사이트 두개가 있다.

1. www.A.com에서 www.B.com으로 API로 정보를 받아오기 시도
2. 프론트에서 HTTP요청을 보냄
3. 서버에서 미리 어떠한 설정을 해주지 않으면 CORS문제로 막히게 된다.

CORS란 이유로 요청을 막는건 www.A.com의 브라우저이다.

동작 방식

1. A서버스에서 B서비스로 요청을 보낸다.
2. 브라우저는 다른 출처로의 요청이므로 요청에 Origin이라는 헤더를 추가한다.

• Origin에는 요청하는쪽의 Scheme(http, ftp, telnet 등)과 도메인, 포트가 담긴다.

3. B서비스의 서버는 응답 헤더에 지정된 Access-Control-Allow-Origin 정보를 실어서 보낸다.

• 만약 A서비스가 등록된 상태면 해당 헤더에 A서비스의 URL도 들어있다.

4. 브라우저가 Origin에서 보낸 출처값이 서버의 답장 헤더에 담긴 Access-Control-Allow-Origin에 있으면 안전한 요청으로 간주하고 응답 데이터를 받아온다.
   없으면 CORS에러가 발생!
5. 토큰 등 사용자 식별 정보가 담긴 요청에 대해서는 엄격하다.

• 보내는 쪽에서는 credential이라는 항목을 true로 세팅
• 받는쪽에서도 모든 출처가 다 된다는 *가 아니라 보내는 쪽의 출처-웹페이지 주소를 정확히 명시한 다음 Access-Control-Allow-Credential항목을 true로 맞춰주어야 한다.

위는 Simple Request라고 해서 Get, Post 등 일정 조건의 요청들에 사용

Put, Delete등 이와 다른 요청들은 본 요청을 보내기전 Preflight 요청이란 걸 먼저 보내서 본 요청이 안전한걸 확인 후 본격적인 요청을 보낼 수 있다.

Preflight Request는 PUT, DELETE, 등과 같이 특정 조건을 충족하지 않는 요청에 대한 사전 확인 요청입니다.

• 서버의 데이터에 영향을 줄 수 있는 요청이기 때문.

출처
얄코 Youtube