CORS란

CORS (Cross-Origin Resource Sharing)란

도메인 또는 포트가 다른 서버의 자원을 요청하는 메커니즘

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

 

 

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

• 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다
• ⭐ 브라우저는 보안 상의 이유로, 스크립트에서 시작한 교차 출처 HTTP 요청을 제한한다.
  ex) domain-a.com ↔domain-b.com 간의 요청은 CORS 정책 위반으로, 브라우저에서 요청을 제한)
• 따라서 다른 출처의 리소스를 불러오기 위해서는, 그 출처에서 교차 출처 리소스 공유에 대한 헤더(CORS)를 응답시 반환 해주어야 한다

---

✔️ CORS는 어떻게 동작하는가?

1. 기본적으로 웹은 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 하는데,
   이때 브라우저는 요청 헤더 (request header)에 Origin 필드에 요청을 보내는 출처를 담아 전송한다.
2. 서버는 요청에 대한 응답을 하는데, 응답 헤더 (response header)에 Access-Control-Allow-Origin이라는 값에 '이 리소스를 접근하는 것이 허용된 출처'를 내려준다.
   이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해 본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.

👉🏻 이것이 기본적인 CORS 동작의 흐름이다. 하지만 모든 CORS 동작의 방식은 아니다.

 

Simple Request

Preflight 요청과는 달리, 예비 요청을 보내지 않고, 서버에게 바로 본 요청을 전송한다.
이 후 서버가 응답 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.

 

Credentialed Request.

인증된 요청을 사용하는 방법이다.

다른 출처 간 통신의 좀 더 보안을 강화하고자 할 때 사용한다. 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다. 이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션이다.

 

---

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

ex)

주소가 '어쩌구'닷컴인 웹사이트에서 url이 '저쩌구'닷컴인 서비스에 API로 정보를 받아오기 위해

'프론트에서' HTTP 요청을 보냈을 때 미리 어떤 설정을 해 주지 않으면 CORS 문제로 막히게 된다.

PostMan, ARC 같은 프로그램으로 요청을 보내거나

스프링 프레임워크를 사용해 백엔드에서 HTTP 요청을 보내면 잘 돼서

이 URL로 GET요청 보내면 되겠구나 하고 '웹사이트'에서 보내보면 안된다(CORS 에러 때문에)

왜 어디서는 안되고 어디서는 되는건가?

 

즉, 웹사이트에서 AJAX 요청을 보낼 때 마다 안된다

즉, 이말은 웹사이트를 여는 곳 크롬, 엣지, 사파리 같은 브라우저에서 일어나는 문제이다

(즉, 프론트엔드에서)

 

CORS란 이유로 요청을 막는건 브라우저 쪽이다.

즉, 크롬이 '사용자'를 못 믿는것이 아니라 '사용자가 방문한 사이트'를 못 믿는 것이다.

 

로그인 유지

내 브라우저에 토큰 등의 정보가 쿠키로 저장 돼서

로그인 했던 사이트에 접속할 때 요청에 실어 보내면 그 사이트에서 이 쿠키를 보고 내가 거기 로그인이 돼 있다.

 

즉, 사용자A가 사이트B에 로그인 돼 있고, 그 상태가 유지되고 있다는 건 사용자A가 사이트B에 접속하거나

그리로 API 요청 등을 보낼 때마다, 해당 요청들이 사용자A로 부터 왔음을 증명하기 위해 같이 보내지는 이 인증 정보가

사용자A의 크롬에 저장되어 있다는 얘기다

그런데 사이트B로 부터 사용자A의 정보를 빼내기 위해 악당들이 사이트C 라는 걸 만들었다.

(사이트B의 정보를 빼내려고 사이트C를 만들었다.)

 

악당들이 사용자A에게 링크가 담긴 메일 또는 그럴 듯한 게시물로 유인하거나 해서

자신들이 만든 사이트C에 접속하도록 유도한다.

 

즉, 사용자A가 사이트C에 접속하게 되면 사이트C에 있는 HTML, CSS, 자바스크립트 코드가

사용자A의 브라우저에 받아진다.

즉, 사이트C에서 받아온 자바스크립트 코드로 악당들이 사용자A의 크롬한테 나쁜 짓을 할 수 있다.

(즉, 사이트B의 인증정보가 들어 있기 때문이다)

즉, 사이트B로 부터 사용자A의 개인정보를 조회하는 요청에 크롬에 저장된 사용자A의 사이트B 토큰을 실어서 사이트B로 보낸다음 그걸로 탈취한 정보를 사이트C 서버로 보낼 수 있다.

 

그렇기 때문에 사용자의 브라우저에 저장된 정보들을 가지고 악의적인 것을 할 수 가 있고

다른 API에다 나쁜 짓을 할 수 있기 때문에 브라우저가 어떤 사이트에서 다른 사이트로 요청이 못가게끔 방지하고 있다.

 

즉, SOP(Same-Origin Policy)로 요청을 막고있다. (동일 출처 정책), CORS는 이것을 풀어준다

즉, SOP로 동일한 출처, 똑같은 URL끼리만 API등의 데이터 접근이 가능하도록 막는거고,

개발자 도구에 CORS 라고 빨갛게 오류가 뜨는 것은 "이게 되게 하려면 CORS란 거를 허용해 주던가 해라"

이런 의미 였다.

 

CORS(Cross-Origin Resource Sharing)는 이것을 풀어준다

Cross-Origin은 Same-Origin과 반대 개념이다.

말 그대로 다른 출처간에 리소스를 공유할 수 있도록 하는 것이다.

즉, 사이트D와 네이버 지도 API 이렇게 서로 다른 출처끼리

정보요청과 반환이 가능하도록 하는게 CORS 이다.

 

서로 다른 출처끼리 요청을 주고 받는건 안되는게 기본값인데 사이트D에서 네이버 지도 API로 요청을 보내는 건

원래 브라우저에서는 애초부터 금지되어 있다.

그런데 이 금지를 풀려고 CORS 를 만든 것이다.

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

 

출처

https://velog.io/@pilyeooong/CORS%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

CORS란 무엇인가 ?

https://www.youtube.com/watch?v=bW31xiNB8Nc