
일단, CORS는 Cross-Origin-Resource-Sharing 이라는 뜻입니다. 번역하면, 교차 출처 리소스 공유 이지요. 출처가 교차한다는게 무슨 뜻일까요?

이 그림은 URL의 구성 요소를 나타내는 그림입니다.
Protocol + Host + Port = Origin
이 세 개가 합쳐진게 바로 Origin 이죠.
이 중 한 가지라도 다르다면, 다른 출처가 되게 됩니다.
참고로 출처 비교와 차단은 브라우저가 합니다.
출처에 대해 알아보았으니, 동일 출처 정책에 대해 알아보겠습니다.
SOP(Same Origin Policy)
동일한 출처에서만 리소스를 공유할 수 있음
동일 출처 서버에 있는 리소스는 자유롭게 가져올 수 있지만, 다른 출처 서버에 있는 리소스는 가져올 수 없음을 의미합니다.
동일 출처만 가능하고 왜 다른 출처는 막아놓았을까요?
과거에는 프론트엔드와 백엔드를 따로 구성하지 않고 한 번에 구성해서 모든 처리가 같은 도메인 안에서 가능했습니다. 그래서 다른 출처로 요청을 보내는 게 의심스러운 행위로 보일 수밖에 없었죠.
실제로 SOP 정책이 없다면, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있습니다.
하지만 시간이 지난 지금은 클라이언트에서 API를 직접 호출하는 방식이 당연해졌습니다. 그런데 보통 클라이언트와 API는 다른 도메인에 있는 경우가 많죠. 그래서 CORS 정책이 생기게 되었습니다. 출처가 다르더라도 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처(Origin)를 명시해 주는 방식으로말이죠.
위에서 말한 것 처럼, CORS는 다른 출처의 리소스 공유에 대한 허용/비허용 정책입니다. 다른 서버의 API를 이용해야하는 상황에서 다른 출처라도 리소스를 받아들이기 위해서죠.
Origin: https://velog.io/@jiwoni1
위 내용에 따르면 CORS 에러를 해결하려면 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 문제가 해결되는 것입니다!
서버에서 Access-Control-Allow-Origin 헤더를 설정해서 요청을 수락할 출처를 명시적으로 지정할 수 있다. 이 헤더를 세팅하면 출처가 다르더라도 https://velog.io/@jiwoni1의 리소스 요청을 허용하게 됩니다.
'Access-Control-Allow-Origin': <origin> | *
*를 설정하면 출처에 상관없이 리소스에 접근할 수 있는 와일드카드이기 때문에 보안에 취약해집니다. 그래서 Access-Control-Allow-Origin': https://velog.io/@jiwoni1과 같이 직접 허용할 출처를 세팅하는 방법이 더 좋습니다.
클라이언트가 리소스를 직접적으로 요청하는 대신, 프록시 서버를 사용하여 웹 애플리케이션에서 리소스로의 요청을 전달하는 방법도 있습니다. 이 방법을 사용하면, 클라이언트 리소스와 동일한 출처에서 요청을 보내는 것처럼 보이므로 CORS 에러를 방지할 수 있습니다.
프록시 서버
Proxy는 대리, 대신이라는 뜻
클라이언트가 프록시 서버 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해준다. 즉, 브라우저와 서버 간의 통신을 도와주는중계서버이다.
예를 들어, 요청해야하는 http://example.com라는 주소의 클라이언트가 http://api.example.com에 데이터를 요청하는 상황이라면...
클라이언트는 직접적으로 리소스에 요청하는 대신, http://example-proxy.com라는 프록시 서버에 요청을 보낼 수 있습니다.
그러면 프록시 서버가 http://api.example.com으로 요청을 전달하고, 응답을 다시 클라이언트에 반환합니다.
이렇게 하면 요청이 http://example-proxy.com보내진 것처럼 보이므로, CORS 에러를 피할 수 있습니다.