[221218] CORS

뜨개발자·2022년 12월 18일
0

WIL

목록 보기
6/14

CORS(Cross-Origin Resource Sharing)

출처 (Origin)

url의 구성 중, Protocol + Host + Port를 Origin이라고 한다.



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

동일 출처(Same-Origin) 서버에 있는 리소스는 자유로이 가져올수 있지만, 다른 출처(Cross-Origin) 서버에 있는 이미지나 유튜브 영상 같은 리소스는 상호작용이 불가능하다는 말이다.

동일 출처 정책이 필요한 이유

해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다.

즉, 안전하지 않은 접근을 막기 위해서이다.

같은 출처와 다른 출처 구분 기준

출처(Origin)의 동일함은 두 URL의 구성 요소 중 Protocol(Scheme), Host, Port 이 3가지만 동일하다면 동일 출처로 판단한다.

출처 비교와 차단은 브라우저가!

그래서 브라우저에는 에러가 뜨지만, 정작 서버 쪽에는 정상적으로 응답을 했다고 하기 때문에 난항은 겪는 것이다.

즉, 응답 데이터는 멀쩡하지만 브라우저 단에서 받을수 없도록 차단을 한 것이다.
이것 때문에 CORS 에러가 발생하는 경우 꽤 오래 답을 찾지 못하고 헤매는 일이 많다고...

해결책

몇 가지 예외 조항을 두고 다른 출처의 리소스 요청이라도 이 조항에 해당할 경우에는 허용하기로 했는데, 그 중 하나가 바로 CORS 정책을 지킨 리소스 요청이다.



CORS(Cross-Origin Resource Sharing) - 교차 출처 리소스 공유

아무리 보안이 중요하지만, 개발을 하다 보면 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야 하는 케이스도 있으며, 또한 실무적으로 다른 회사의 서버 API를 이용해야 하는 상황도 존재한다. 따라서 이와 같은 예외 사항을 두기 위해 CORS 정책을 허용하는 리소스에 한해 다른 출처라도 받아들인다는 것이다.

브라우저의 CORS 기본 동작

  1. 클라이언트에서 HTTP요청의 헤더에 Origin을 담아 전달

    기본적으로 웹은 HTTP 프로토콜을 이용하여 서버에 요청을 보내게 되는데, 이때 브라우저는 요청 헤더에 Origin 이라는 필드에 출처를 함께 담아 보내게 된다.


  2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.

    이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더에 Access-Control-Allow-Origin이라는 필드를 추가하고 값으로 '이 리소스를 접근하는 것이 허용된 출처'를 내려보낸다.


  3. 클라이언트에서 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.

    이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 차단할지 말지를 결정한다.

    만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. (CORS 에러 !!)



결국 CORS 에러를 해결하려면 서버에서 Access-Control-Allow-Origin 헤더에 허용할 출처를 기재해서 클라이언트에 응답하면 되는 것이었다. 즉, 백엔드 개발자가 고쳐야될 부분인 것이다.

CORS를 해결하는 방법

Chrome 확장 프로그램

'Allow CORS: Access-Control-Allow-Origin'을 이용하는 방법이다.
로컬(localhost) 환경에서 API를 테스트 시, CORS 문제를 해결할 수 있다.

서버 테스트 환경에서 고민하지 않고 빠르게 CORS를 해결하는데 좋은 선택지가 될 수 있다.

프록시 서버 활용

프록시는 모든 출처를 허용하는 서버 대리점의 개념이라고 보면 된다.
다만, 무료 프록시 서버의 경우에는 대부분이 api 요청 횟수에 제한이 있어 테스트 용으로는 모를까 실전에서 사용하기에는 무리가 있다.
실전에서 사용하고자 한다면 직접 프록시 서버를 구축해야 한다.

Access-Control-Allow-Origin 헤더 세팅

직접 서버에서 HTTP 헤더 설정을 통해 출처를 허용하게 설정하는 가장 정석적인 해결책이다.
각 서버의 문법에 맞게 위의 HTTP 헤더를 추가해 주면 된다.







하단 사이트에서 내용을 발췌하여 공부하기 위해 재편집하였습니다.
개인의 공부를 위한 요약본과 같으니, 이후에라도 다시 공부하고자 한다면 링크를 통해 진행해야 합니다.
[링크텍스트](https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F#CORS%EB%A5%BC
%ED%95%B4%EA%B2%B0%ED%95%98%EB%8A%94%EB%B0%A9%EB%B2%95%EC%B4%9D%EC%A0%95%EB%A6%AC%F0%9F%99%8C)

profile
뜨개질하는 개발자

0개의 댓글