
웹 개발을 하면 반드시 마주치는 에러인 CORS에 대해서 심심하지 않게 겪어봤을 것이다.
프론트엔드나 백엔드에서 문제없이 모든게 멀쩡한데 요청한 자료에 대해 응답을 아래처럼 에러로 준다.

우선 CORS가 무엇인지 개념을 파악해보자.
Cross-Origin Resource Sharing으로 직역하면 동일 출처 리소스 공유 정책을 말한다.HTTP Origin 필드에 자신의 출처를 담아 리소스 서버에 요청하는 것이다.여기서 출처는 URL 경로를 의미하고 프로토콜, 호스트, 포트 번호를 포함하고 있다.
이 세가지 구성요소가 모두 일치하면CORS를 신경 쓸 필요가 없지만, 하나라도 일치하지 않는다면CORS를 설정해 리소스 서버에 요청해야 한다.
앞서 말했듯이 구성요소가 같아야 동일 출처(Origin)이라고 한다.
동일한 출처 예시를 가져와봤다.
다른 출처는 다음과 같다.(CORS 정책 위반)
SOP는 Same-Origin Policy의 약자로 동일한 출처에서만 리소스를 공유할 수 있는 정책이며, CORS와 반대되는 개념이다.SOP는 기본적으로 웹 보안을 강화하기 위해 설계되었는데, 다른 출처에서의 접근을 막아 악의적인 공격이나 정보 유출을 방지할 수 있다.프론트에서 백으로 API 요청을 보낼 때 흔하게 발생하는데 JavaScript에서는 기본적으로 서로 다른 출처의 리소스 공유를 제한하고 있으며, 하나의 컴퓨터 내에서도 프론트와 백이 설정된 포트 번호가 다르다. 따라서 프론트는 HTTP 헤더 Origin 필드에 출처를 담아 요청하고, 백은 HTTP 헤더 Access-Control-Allow-Origin 필드에 허용하는 출처를 담아 응답해야 한다.
이유는 단순하다. 보안상 위험하기 때문이다. 브라우저는 공격에 굉장이 취약하다. 두 어플리케이션이 자유롭게 통신할 수 있으면 꽤 위험한 환경이라고 생각이 들지 않는가?
CORS의 여부는 브라우저가 판단한다. 클라이언트에서 출처를 허용해줘야 한다고 생각하기 쉽지만 실제로는 서버측에서 출처(Origin)을 기재해줘야만 CORS를 우회할 수 있게 된다. 그렇다면 CORS의 동작구조를 알아보자.
기본적으로 브라우저에서 서버로 요청을 보낼 때 HTTP 프로토콜을 사용하게 된다. 이 때 브라우저는 요청 헤더에 Origin이라는 필드에 출처를 담아 보내게 된다.

여기에서 출처는 위에서 언급했듯이 프로토콜, 호스트, 포트가 모두 같아야 한다는 것을 잊지말자!
이제 이 요청에 서버가 받고 이에 대한 응답을 보낼 것이다.

서버는 응답을 보낼 때 응답 헤더에 Access-Control-Allow-Origin이라는 필드를 추가하게 된다. 여기에 담겨있는 값응 이 리소스를 접근하는 것이 허용된 출처 URL이다.
이후 응답을 받은 브라우저는 자신이 보낸 요청 헤더의 Origin과 서버가 보낸 응답 헤더의 Access-Control-Allow-Origin을 교하여 차단해야 할지 말지를 결정한다. 만약 출처가 동일하지 않다면 CORS 오류가 나오게 되는 것이고, 동일할 경우 해당 요청이 유효하다고 판단하게 되어 제대로 응답을 받을 수 있게 된다.
CORS를 해결하기 위해서는 방법은 클라이언트단이랑 서버단에서 가능하다. 실제로 오류 해결하는 방법은 다른 여러 블로그에서 찾아 볼 수 있어 이 글에서는 CORS 개념과 발생 원인에 초점을 두었다.
헐 CORS 에러 얼마전에 플젝 하면서 봤어요~~