CORS란? - CORS (1)
개요
최근 앱 서비스 프로젝트만 하다가, 다시 웹 서비스 프로젝트를 하며 CORS 설정 덕분에 애를 좀 먹었다. CORS 개념을 간단히 정리하고 설정 관련 이슈들을 공유하려고 한다.
CORS란?
Cross-Origin Resource Sharing의 약자로 동일하지 않은 출처(Cross Origin)의 요청을 허용하는 정책이다.
즉 리소스를 요청한 곳의 출처가 서버와 다르더라도 제한적으로 허용하도록 하는 것이다.
출처란?
URI의 구성요소 중 Protocol, Host, Port의 조합을 의미한다.
https://example.com:8080
서버에서 허용한 출처가 다음과 같다고 하자.
아래와 같을 경우 동일하지 않은 출처가 된다.
- Protocol이 다른 경우 -> http://example.com:8080
- Host가 다른 경우 -> https://examples.com:8080
- Port가 다른 경우 -> https://example.com:3000
왜 출처를 검증? 바로 CSRF 대비
서버에서 허용하지 않은 출처를 구분하게 된다면, 다른 사이트에서 원래 사이트를 모방하여 사용자의 중요 정보를 탈취할 수도 있다.
아래 시나리오를 보자.
원래 은행 -> https://mybank.com
다음과 같은 은행이 있다.
해커가 만든 모방 은행 -> https://mybanks.com
사용자가 해커가 만든 모방 은행 페이지로 접근해버렸다!
만약 서버에서 출처를 검증하지 않는다면, 모방 은행 페이지에서는 사용자의 동작을 이끌어내어 원래 은행 페이지로 API를 호출할 수 있고, 해커는 중요 정보 및 토큰을 탈취하여 추가 피해를 입힐 수도 있을 것이다.
이러한 공격을 CSRF(Corss-Site Request Fogery)라고 하며, CORS를 통해 출처를 검증한다면 CSRF를 대비할 수 있을 것이다.
브라우저에서의 동작
특정 상황을 제외한다면, 브라우저에서는 대게 API를 통해 서버에 요청하게 되면, 다음과 같이 요청이 2개가 발생하게 된다.
- Preflight 요청 -> 출처 검증
- 실제 우리가 한 요청
브라우저는 Preflight 요청을 통해서 해당 출처에서 실제 요청을 보내는 것이 안전한지 확인한다. 만약 CORS 정책 위반이라면, 브라우저에서 실제 요청을 호출하지 않는다.
💡브라우저를 통한 요청이 아니라면 CORS 정책은 적용되지 않는다.
Preflight 요청 응답
Preflight 요청과 응답에는 아래와 같이 필수적으로 포함되는 헤더들이 있다.
요청
- Origin - 출처
- Access-Control-Request-Method : 실제 요청 시 HTTP 요청 메서드
- Access-Control-Request-Headers : 실제 요청 시 Header들
응답
- Access-Control-Allow-Origin : 출처가 자원 접근에 허용됨
- Access-Control-Allow-Methods : 실제 요청 시 허용되는 메서드
- Access-Control-Allow-Headers : 실제 요청 시 허용되는 헤더
- Access-Control-Allow-Credentials : 실제 요청에 대한 응답에 접근할 수 있는지