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개가 발생하게 된다.

1. Preflight 요청 -> 출처 검증
2. 실제 우리가 한 요청

브라우저는 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 : 실제 요청에 대한 응답에 접근할 수 있는지