CORS(Cross-Origin Resource Sharing)
직역하면 '교차 출처 리소스 공유'이다. 처음 이 말을 들었을 때 무슨 말인지 몰랐다. 그래서 이렇게 생각하는 편이 나을 것 같다. '다른 출처에 있는 리소스를 공유하는 것'.
여기서 또 이해가 가지 않는 부분은 Origin(출처)이다.
대략적으로 도메인이라고 생각하면 된다. (도메인이란 ip주소에 이름을 부여한 것을 말한다. 예를 들어 naver.com 과 같은 url이 있다.) 더 구체적으로는 scheme, protocol, host, path, query string, fragment, port등을 포함한 서버의 위치를 말한다.
골치아픈 CORS 정책 위반
골치아픈 CORS 정책을 왜 지켜야 하는걸까?
클라이언트 어플리케이션은 사용자의 공격에 굉장히 취약한 구조이기 때문이다. 개발자 도구만 열어도 DOM이 어떻게 작성되었는지, 리소스 출처는 어디인지 등등 아무런 제재없이 확인이 가능하다. 또한 자바스크립트 코드를 아무리 난독화해도, 해석이 불가능한 것이 아니기 때문에 보안에 상당히 취약하다.
그렇다면 다른 출처와 같은 출처는 어떻게 구분하는 것인가?
URL 구성 요소 중 Scheme, Host, Port 가 동일하면 된다.
그렇다면 다른출처에 있는 리소스를 공유하려면 어떻게 해야 할까?
CORS 동작시키는 방법
클라이언트 앱에서 CORS를 할때는 HTTP 프로토콜을 사용하여 요청을 보내게 된다.
이후 서버가 요청에 대해 응답을 할 때 헤더의 Access-Control-Allow-Origin이라는 값에 이 리소스에 접근하는 것이 허용된 출처를 보낸다. 이후 응답을 받은 브라우저는 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin 을 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.
하지만 사실 CORS가 동작하는 방식은 세가지의 시나리오에 따라 변경되기 때문에 어떤 시나리오에 해당하는지 잘 파악하면 CORS 정책 위반으로 인한 에러를 고치는 것이 한결 쉬울 것이다.
세가지 시나리오에는 PreFlight Request, Simple Request, Credentialed Request 가 있으며,
자세한 내용은 아래 링크를 참고하라!
References
https://evan-moon.github.io/2020/05/21/about-cors/
CORS는 왜 이렇게 우리를 힘들게 하는걸까?
이번 포스팅에서는 웹 개발자라면 한번쯤은 얻어맞아 봤을 법한 정책에 대한 이야기를 해보려고 한다. 사실 웹 개발을 하다보면 CORS 정책 위반으로 인해 에러가 발생하는 상황은 굉장히 흔해서
evan-moon.github.io
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS
교차 출처 리소스 공유 (CORS) - HTTP | MDN
교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라
developer.mozilla.org