CORS에 대해서 알아보자
CORS의
서론
우리가 웹 페이지를 만들때 서로 다른 출처끼리 리소스를 공유하는 일이 생길 수 있다.
이때 다른 출처로부터 들어온 리소스의 보안상 안정성에 대해서 생각해봐야한다.
오늘은 이를 위해 만들어진 정책을 알아보자.
출처?
서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐놓은 것이다.
출처를 구분하는 방법
출처는 URL의 구성요소인 Scheme, Host, Port 이 3가지를 비교해보면 알 수 있다.
Port는 일반적인 경우 http/https 의 기본포트를 사용하고, 다른 경우 url의 맨 끝에 붙어있다.
Scheme는 https://, 그리고 이 뒤에 붙은 url주소를 호스트라고한다.
이 3가지가 같으면 같은 출처라고 인식되는 것이다.
SOP?
Same-Origin Policy
서론에서 말한 것처럼 서로 다른 출처끼리 리소스를 공유한다면 보안에 대해 생각해봐야한다.
그렇기때문에 만들어진 정책으로 “같은 출처에서만 리소스를 공유할 수 있다.” 라는 규칙을 가진 정책을 SOP라고한다.
왜 이런 정책이 존재할까?
출처가 다른 두개의 어플리케이션이 아무런 규칙없이 소통할 수 있는 환경은 매우 위험하기 때문이다.
어플리케이션끼리의 통신에 아무런 제약이 없다면 사용자가 CSRF, XSS 등 임의로 코드를 실행시켜 사용자 정보를 탈취하는등 악의적인 행동을 할 수 있기 때문이다.
그럼 어떻게 해야할까?
하지만 다른 출처에 있는 리소스를 사용하는일은 굉장히 흔한일이기때문에 조건부로 허용해주었는데, 그 조건 중 하나가 CORS 정책을 지킨 리소스 요청이다.
CORS
Cross-Origin Resource Sharing
CORS는 서로 다른 출처로부터 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의한다.
웹 페이지 상의 제한된 리소스를 다른 출처로부터 현재의 출처가 요청할 수 있게 허용하는 구조다.
CORS의 구현방법
CORS의 구현방법으로는 두가지 방법이 있다.
Preflight Request
CORS의 구현방법 중에 하나로 브라우저가 예비 요청과 본 요청을 나눠서 서버에 전송하는 방식이다.
여기서 예비 요청을 Preflight라고 부른다.
예비요청의 역할은 본 요청을 하기전 브라우저 스스로 이 요청이 안전한지를 확인하는 것이다.
브라우가 리소스를 서버에 요청하기전 예비 요청을 보내고, 그 예비 요청에 대한 응답으로 서버에서 어떤 것을 허용하고 어떤 것을 금지하는지에 대한 정보를 응답 헤더에 담아서 받는다.
브라우저는 자신이 보낸 예비 요청과 서버가 응답에 담아준 허용 정책을 비교한 후, 이 요청을 보내는 것이 안전하다고 판단 되면 본 요청을 서버로 보낸다.
Simple request
CORS의 구현방법 중에 하나로 서버에게 바로 요청을 보내는 방법이다.
예비 요청 없이 바로 요청을 보내어 돌아오는 응답헤더에서 Access-Control-Allow-Origin이 있는지 없는지 브라우저 자체에서 검사하는 방식이다.
하지만 아무런 조건없이 사용할 수 있는 방법은 아니고 특정 조건 몇가지를 만족해야 사용할 수 있다.
Simple request 의 조건
- 요청된 메소드는 get, head, post 중 하나여야한다.
- Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
- 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.
이렇듯 조건이 까다로워 많이 쓰이는 방식은 아니다.
마치며
오늘은 출처, 그리고 서로 다른 출처끼리의 리소스 공유가 위험한지, SOP, CORS와 같은 것들을 왜 지켜야하는지를 알아봤다.
웹을 공부하다보면 보안상으로 신경써야하는 부분이 많은 것 같다.