CORS(Cross-Origin Resource Sharing) 의 개념

RumbleBi·2022년 6월 4일
0

Front-end

목록 보기
2/15
post-thumbnail
post-custom-banner

CORS ERROR는 왜 발생하는가?

내가 웹 사이트를 만드려는 경우, 다른 사이트 API 에다 AJAX 요청을 보내서 리소스를 받아오려 한다면 아마 크롬 개발자 도구에서 CORS ERROR 가 발생했을 것이다.

주소가 A 인 웹 사이트에서 URL이 B 인 서비스에 API로 정보를 받아오기 위해 프론트에서 http 요청을 보냈을 때, 특정 설정을 해 주지 않으면 CORS ERROR 가 발생하는 것이다. 혹여 postman으로 데이터를 요청하는 경우에는 잘 되기 때문에 헷갈리기 쉬운 문제이다.

그렇다면 왜 요청하는 주체에 따라 CORS error 가 발생하는 것일까?

그것은 웹 사이트를 여는 애플리케이션 즉, 크롬, 엣지, 사파리같은 브라우저 에서 일어나는 문제기 때문이다. 더 자세히 말하면 CORS 로 인해서 막히는 것은 외부 API를 보내주는 측에서 막은 것이 아닌, 브라우저에서 우리가 만든 웹 사이트를 신뢰할 수 없기 때문에 외부 API 사이트의 요청을 막는 것이다.

사실 그렇게 보이는 것 뿐이고, SOP (Same-origin Policy)가 막고, CORS 가 제한을 풀어주는 역할이다. 개발자모드에 나타난 CORS ERRORCORS 를 허용하라는 메시지인 셈이다.

그렇다면 CORS는 무엇인가?

Same-origin 과 반대되는 개념으로 다른 출처간에 리소스를 공유할 수 있도록 해 주는 것 이다. 출처웹 사이트와 API의 주소 , 리소스주고 받는 데이터 라고 생각하면된다. 즉 이것들의 요청반환 이 가능하도록 해주는 것이다.

그러면 SOP(Same-origin Policy)는 뭐지?

말 그대로 동일한 출처 , URL 끼리만 API 등의 데이터 접근 이 가능하도록 막는 것이다. 원래 브라우저에서 타 사이트간의 데이터를 요청하는 것은 금지 되어 있었고 이것이 SOP 이다. 그러나 브라우저 환경이 발달함에 따라, 웹 사이트 간에 데이터를 주고받을 일이 생겼고, 이에 대해 CORS 라는 것이 탄생하게 된 것이다.

CORS를 사용하기 위한 조건

요청을 받는 백엔드 에서 이 요청을 허락할 다른 출처들을 명시 해 두면되는 것이다. CORS 옵션에서 허용할 사이트를 적으면 그 사이트에서는 이 서버로 얼마든지 http 요청을 보낼수 있게 되는 것이다.

아무나 보내도 되는 경우는 별표나 와일드카드를 적으면 누구나 요청을 보낼 수 있다.

브라우저는 다른 출처끼리의 요청이 보내질 때는 요청에 origin 이라는 header 를 추가한다. header 는 데이터가 다른 곳으로 전송될 때, 데이터의 맨 앞쪽에 붙는 정보 다. 받는 쪽의 IP주소 , 사용할 프로토콜 이나 옵션 등이 담긴다. 이 origin 안에는 요청하는 쪽의 scheme , 도메인 , 포트 가 담긴다.

scheme이란 요청할 자원에 접근할 방법 http , ftp , telnet 등을 말한다.
예시로 https 가 scheme을 의미하고 naver.com이 도메인이고, 만약 :443 같은 포트번호가 붙어있으면 그것이 포트다.

그럼 이 요청을 받은 API서버는 리소스를 보내면서 header 에 지정된 Access-Control-Allow-Origin 정보를 같이 보내준다. 그 후 크롬이 둘을 비교해서 origin 에서 보낸 출처값이 서버의 데이터에 붙은 header 에 담긴 Access-Control-Allow-Origin 이 같으면 안전한 요청 으로 간주하고, 응답 데이터를 받아오는 것이다.

그리고 token사용자 식별 정보 가 담긴 요청에는 보다 엄격 하다.
보내는 측에서는 요청의 옵션에 credentialstrue 로 세팅하고 받는 쪽에서도 아무 출처나 받지 않고 보내는 쪽의 출처, 주소를 정확히 명시 하고 Access-Control-Allow-Credentialstrue 로 맞춰야한다.

왜 이렇게 엄격할까?

모종의 이유로 외부에서 해킹이 들어와 브라우저 안의 쿠키를 조작하였고, 그대로 사용한다면 문제가 될 수 있기 때문에 양쪽에서 조건을 강하게 걸어놓는 것이다. 그리고 이러한 방식은 Simple request 라고 해서 GET , POST 등 일정 조건의 요청들에 사용되며 요청을 보내지만 통과를 못하면 리소스를 받지 못한다.
PUT, DELETE 과 같은 다른 요청들은 보내기 전에 Preflight 요청을 먼저 보내서 이 요청이 안전한지 확인하고 허락이 되어야 요청을 보낼 수 있다. 왜냐면 이것들은 서버의 데이터에 영향을 줄 수 있는 요청들이기 때문에 요청을 보내는것도 허락을 받아야 한다.

그럼 simple request로 보내는 것은 안전한가?

그렇지 않다. simple request로 보내는 것들도 신경쓰지 않는다면 서버에 저장된 데이터가 변경될 수도 있다. 그래서 SOP만으로는 한계가 있고, 추가적인 보안 설정을 해야되는 것이다.

profile
기억보다는 기록하는 개발자
post-custom-banner

0개의 댓글