
브라우저는 기본적으로 same-origin policy 를 갖는다. cors 를 이해하기 전 알고 지나가자
어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 체한하는 중요한 보안 방식


cross-origin 요청이 필요한 상황이 많아지며 안전하게 처리할 정책이 필요해졌다. 그래서 등장한게 CORS이다.
- 프론트와 백엔드의 서버 분리
현대 웹 애플리케이션는 빠른 서비스를 위해 서버가 크게 프론트와 백엔드로 나누어졌다.
클라이언트 측에서 요청을 하는 순간 프론트 서버의 응답을 받아 랜더링이 되고, 데이터는 백엔드 서버에 요청하여 받아오게 되는 흐름은 SOP 때문에 처리의 한계를 가졌다.- 다른 출처의 데이터 사용
웹 구현시 다른 출처의 데이터를 요청해 써야하는 경우가 많아졌다.- 마이크로 서비스 아키텍쳐
트래픽양이 증가하면서 서버 한대로는 물리적으로 버티기 힘들어졌고 여러개 서버의 필요성이 대두됐다.
a 서버는 로그인 관리를 위한 서버, b는 주문만 받는 서버처럼 하나의 서버가 특정 기능만을 수행하도록 분할하여 관리된다.
cross-origin 요청을 제한적으로 허용함으로써 좀 더 안전하게 cross-origin 요청을 처리할 수 있는 정책이다.
프로토콜, 호스트(도메인), 포트번호가 동일하면 CORS 허용 기준이 되어 동일 출처(origin)으로 본다.
CORS는 추가 HTTP 헤더를 사용하며, 한 출처에서 실행중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다. 웹 애플리케이션은 리소스가 자신의 출처와 다를 때 교차 출처 http요청을 실행한다.
서버쪽에서 cors를 허용하면 B서버의 응답 허용
