CORS 에러 1분 요약

💡 chatGPT에게 CORS 에러에 대해 초등학생도 이해할 수 있게 설명해달라고 부탁해보았다.

(의역 포함)
🤖 친구들과 공을 서로에게 패스하는 게임을 해본 적이 있나요? 당신과 당신의 친구들이 서로에게 공을 던지는 게임을 하고 있는데, 공은 옆에 서 있는 사람에게만 던질 수 있다는 규칙이 있습니다. 즉, 멀리 서 있는 친구에게 공을 던질 수 없습니다!

 CORS는 그런 규칙을  웹 사이트에 적용한 것입니다. 웹 사이트를 방문하면 컴퓨터가 해당 웹 사이트에 사진이나 비디오와 같은 정보를 달라고 요청을 보냅니다. 하지만 공놀이 게임에서와 마찬가지로 누가 그 정보를 얻을 수 있는지에 대한 규칙이 있습니다.

 CORS는 공놀이 게임에서 멀리 떨어진 친구에게 공을 던질 수 없는 것과 같이 일부 웹사이트가 서로 옆에 서 있지 않으면 다른 웹사이트에서 정보를 얻을 수 없다는 규칙입니다.이는 웹 사이트를 방문할 때 정보를 도용하려는 나쁜 사람으로부터 컴퓨터를 안전하게 보호하기 위한 것입니다. 마치 파티에 오고 싶어하는 모든 사람이 나쁜 사람이 아닌지 확인하는 경비원과 같습니다. 따라서 CORS는 인터넷을 사용할 때 우리의 정보를 안전하게 보호하는 데 도움이 되는 규칙입니다.

 

 기가막힌 설명이 아닐 수 없다... AI가 삶을 크게 변화시킬 날이 머지 않아 보인다. 아무튼 위 내용을 숙지하고 읽으면 빠른 이해에 도움이 될 것이다.

 

📌 CORS(Cross-origin-resource-sharing, 교차 출처 리소스 공유 정책) 

• 다른 출처 간의 리소스 요청을 허용하는 정책이다.

 

출처(Origin)란?

http://www.suzuworld.com:3000/user?query=number... 

에서 

http:// : Protocol ,   www.suzuworld.com : Host ,   :3000 : Port

을 합친 URL을 의미한다.

 

 

이렇게만 봐서는 아직 잘 모르겠다. CORS가 왜 생기게 되었는지 흐름을 살펴보자.

 

동일 출처 정책(Same-Origin Policy, SOP)

• 동일한 출처 사이에서만 리소스를 공유할 수 있는 정책이다.

 

왜 이러한 정책이 생겼을까?

• 출처가 다른 애플리케이션이 서로 자유롭게 소통하게 된다면, 우리의 개인정보는 너무나도 쉽게 해킹당할 수 있기 때문이다.

<예시>

사용자가 실수로 악성 웹 사이트에 접속한다. 이때 해커가 심어놓은 악의적인 자바스크립트가 실행된다.

1. 사용자가 모르는 사이에 일반 웹 사이트에 요청을 보낸다. 이 사이트는 포털 사이트로 사용자가 로그인한 기록이 브라우저의 쿠키 안에 담겨있다.
2. 상호 작용을 통해 개인 정보를 포털사이트로부터 응답값으로 받는다.
3. 이 응답값을 해커가 만든 웹 사이트로 재차 보낸다.

 이밖에도 사용자가 접속중인 내부망의 아이피, 포트 등을 탈취하거나, 사용자의 브라우저를 프록시처럼 악용하는 등 다른 출처의 스크립트를 실행시키므로써 해킹의 위험에 쉽게 노출된다. 이를 방지하고자 SOP 정책을 디폴트로 둠으로써 다른 출처의 스크립트는 실행되지 않고, 동일한 출처 사이에서만 리소스를 공유할 수 있게 규칙을 정해놓은 것이다.

 

 

같은 출처인지 구분 하는 기준

• 위에서 언급했듯이 Protocol(Scheme), Host, Port 3가지가 동일하다면 동일 출처로 구분한다.

 

 

출처 비교 및 차단하는 주체

• 브라우저에서 출처를 비교하고 동일하지 않으면 차단한다. 서버가 아니다.

 

 

이제 다시 CORS로 돌아가보자.

• CORS는 다른 출처 간의 리소스 공유를 허용하는 정책이다.
• SOP로 인해 출처가 다르면 리소스 공유가 불가능했지만, CORS로 인해 다른 출처의 리소스를 허용할 수 있게 된 것이다.

 

어떻게?

• 클라이언트(브라우저)에서 HTTP 요청 헤더에 Origin을 담아 전달한다.
• 서버는 응답 헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다. 이때 값으로 '이 리소스를 접근하는 것이 허용된 출처 url'을 담아 내보낸다.
• 클라이언트는 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교하여 자신이 요청 헤더에 보낸 Origin이 서버의 응답 헤더에 있는 Access-Control-Allow-Origin 안에 있다면 다른 출처라도 리소스를 공유하도록 한다.
• 없는 경우에는 그 유명한 CORS 에러를 내보낸다. (악성 웹 사이트는 출처 url 목록에 없기 때문에 CORS 에러가 나게 된다.)

 

결론

• 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 담아 클라이언트에 응답으로 보내면 다른 출처 간의 리소스 공유를 가능하게 한다.

 

 

참고 :

https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏