CORS의 정의

CORS는 Cross Origin Resource Sharing의 약자로, 교차 출처 공유라는 의미이다.

Origin은 ① scheme, ② host, ③ port 로 이루어진 도메인을 의미한다. (IE의 경우 port를 비교하지 않음)

https://www.naver.com/

① scheme : https
② host: www.naver.com
③ port: null (공개되지 않음)

현재 ① 자신이 속한 출처(Origin)를 기준으로 ② 다른 출처(Origin)에 API를 요청하게 되면 브라우저에서 이 요청으로 넘어오는 경과가 안전한지 판단하게 되는데,

응답을 보내는 출처가 ① 자신이 속한 출처가 아닌, ② 다른 출처여도 서로 예상되는 출처라면 요청에 대해 허용해주는 응답 헤더를 보내, 브라우저가 응답 결과를 보여준다.

이를 CORS(Cross Origin Resource Sharing)이라 한다.

---

CSRF 공격

초기의 브라우저를 이용하는 클라이언트는 모두 자유롭게 데이터를 요청하고, 응답할 수 있었다.
하지만 초기의 브라우저는 많은 보안상 문제점을 안고 있었다. 해커가 만든 피싱 사이트에 접속했을 때, 해커가 원하는 요청대로 클라이언트가 요청한 것으로 이루어지는 보안상 문제점이 발생했다.

이를 CSRF 공격이라고 부른다

---

SOP의 탄생

치명적인 보안 단점을 안고 있던 초기의 브라우저는 한 가지 대안을 찾게 된다.
출처에 대해서 완벽히 같아야 데이터를 응답해주는 엄격한 출처 비교 보안 정책을 세우게 되는데,

이를 SOP라고 부른다.

그럼 SOP가 어떻게 보안 취약성을 보완했는 지 알아보자.

도메인의 비교

IE 등의 브라우저는 다른 기준으로 비교하기도 하지만,
대다수의 브라우저는 scheme + host(Domain Name) + port로 출처 일치 여부를 판단한다.

따라서 브라우저는 SOP 방식을 통해 scheme, host, port 세 가지가 모두 같으면 같은 출처, 하나라도 다르면 다른 출처로 인식하여 요청한 출처와 응답할 출처가 같은 곳인지를 비교하여 보안성을 높였다.

---

SOP의 한계

시간이 흘러 개발자들은 어떻게 다른 웹사이트의 유용한 API를 주고받을 수 있을 지에 대한 고민이 깊어가는 중, JSONP 를 이용하여 API 통신을 할 수 있는 트릭을 발견하게 된다.
JSONP?


SOP 입장에서는 클라이언트가 제대로 된 요청을 하지 않고 다른 출처를 통해 우회하게 되는 취약성을 갖게 되었다. 이 보안성 취약점을 보완하기 위해 SOP는 다른 출처여도, 이미 예상되는 출처라면 서버에서 허용해주는 응답 헤더를 보내, 브라우저가 응답 결과를 보내주는
CORS(Cross Origin Resource Sharing) 방식이 태어났다.

---

브라우저의 CORS

브라우저가 CORS 요청을 처리하는 이유

브라우저가 CORS 요청을 처리하는 이유는 모든 서버들이 다 CORS를 인지하지는 않기 때문이다.

결과적으로 브라우저는 거부했다고 하더라도, 서버는 처리해버리는 결과가 생길 수 있기 때문에
서버가 안전하게 요청을 주고받을 수 있도록 브라우저에서 해당 요청(CORS)을 처리한다.

실제 요청에서는 어떻게 처리하는가?

CORS는 다른 Origin에 대한 요청을 허용하는 정책이다.

같은 Origin에서 http 통신을 하는 경우 알아서 cookie가 request header에 들어가지만, 교차 출처로 요청하는 상황에서는 그렇지 않다.

Origin이 다른 http 통신에서는 request header에 쿠키가 자동으로 들어가지 않기 때문에 서버에게 또는 클라이언트에게 내가 어떤 요청을 보내는 지 알려줄 필요가 있다.

프론트 > WithCredentials: true

서버 > Access-Control-Allow-Credentials: true

즉 CORS는 다른 출처의 자원을 공유하는 것이라고 할 수 있고,
추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이
다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.