Same-Origin Policy의 줄임말로, 동일 출처 정책을 뜻한다. 즉, 같은 출처의 리소스마나 공유가 가능하다'는 말이다.

출처(Origin)란 프로토콜, 호스트, 포트의 조합으로 이루어져있다. 이 중 하나라도 다르면 동일한 출처라고 볼 수 없으며, 이러한 정책은 해로울 수 있는 문서로부터 공격받을 수 있는 경로를 줄여준다. 해킹 등의 위협에서 안전해질 수 있기 때문에 모든 브라우저에서 기본적으로 사용하고 있는 정책이다.
SOP는 보안상의 이점 때문에 많이 사용되지만, 다른 출처의 리소스를 사용하게 되는 경우에서 문제가 생긴다. 개발 중인 웹 사이트에서 날씨 API를 받아오고 싶거나, 클라이언트와 서버를 따로 개발할 때 등 다른 출처의 리소스를 사용해야 하는 일에 문제가 생긴다. 이러한 문제 상황을 해결하기 위해 CORS가 등장했다.
CORS는 Cross-Origin Resource Sharing의 줄임말로 교차 출처 리소스 공유를 뜻한다. CORS를 사용하면 접근 권한을 얻을 수 있다.
실제 요청을 보내기 전, OPTIONS 메서드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지부터 확인한다. 브라우저는 서버에 실제 요청을 보내기 전에 프리플라이트 요청을 보내고, 응답 헤더의 Access-Control-Allow-Origin으로 요청을 보낸 출처가 돌아오면 실제 요청을 보낸다. 만약에 요청을 보낸 출처가 접근 권한이 없다면 브라우저에서 CORS 에러를 띄우게 되고, 실제 요청은 전달되지 않는다.
프리플라이트는 실제 요청을 보내기 전에 확인할 수 있기 때문에 리소스 측면에서 효율적이다. 또한 CORS에 대비가 되어있지 않은 서버를 보호할 수도 있다.
특정 조건이 만족되면 프리플라이트 요청을 생략하고 요청을 보낸다.
조건은 GET, HEAD, POST 요청 중 하나여야하며, Accept-Language, Content-Language, Content-Type 헤더의 값만 수동으로 설정할 수 있다.
출처가 다를 경우에는 별도의 설정을 하지 않으면 쿠키를 보낼 수 없다. 이 경우에는 클라이언트, 서버 양측 모두 CORS 설정이 필요하다.

CORS문제는 프론트엔드 개발자라면 언젠가 한 번은 꼭 거쳐야 할 문제예요ㅎㅎㅎㅎ아마 지금 잘 알고 가더라도 나중에 부딪히고 '이게 대체 왜 안 되지??' 라는 사태가 발생하죠😅