Server - CORS

#1. CORS (Cross - Origin Resoure Sharing)가 나오게 된 배경

 

예전에 웹사이트를 만든다고 하면 상당수가 아래와 같은 구조였습니다. 유저가 웹 브라우저 주소창에 주소값을 입력 하면 해당하는 서버로 요청을 보내게 됩니다. 

그러면 서버에서는 응답을 할 때 HTML페이지를 반환합니다. 즉 하나의 서버에서 비즈니스 로직과 HTML페이지 빌드를 같이 하는게 일반적이였습니다. 이걸 다시 말하면 같은 도메인에서 일어나게 된거죠 하지만 이러한 구조는 CSRF나 XSS 공격을 받기 일수 였습니다. 즉 개인정보 유출, 피싱 사이트와 같이 보안상 악의적인 행동으로 인해서 도메인이 다르면 요청을 주고 받을수 없도록 웹브라우저에서 기본 정책을 시행하게 됩니다.

 

하지만 시간이 지나 웹사이트에서 할 수 있는 일들이 점점 많아지기 시작했습니다! 문서를 작성하는 것 뿐만 아니라 어플리케이션이나 다양한 웹 서비스들을 만들기 시작합니다. 그런데 기존 웹 브라우저 보안 정책으로 인해서 불편한점이 생기기 시작합니다.

예를 들어 위와 같이 어떤 프로잭트에서 날씨 정보를 제공해주는 서비스를 추가하려고 하는데 보안정책으로 인해서 서버를 거쳐야 되는 상황이 발생합니다. 그래서 이러한 문제를 해결하고 웹브라우저에서 바로 api서버를 제공 받을 수 있도록 하기위해 CORS (Cross-Origin Resoure Sharing)사용하게 됩니다. 다시 말해 브라우저에 두개 이상에 서버와 연결 되는 것을 예외적으로 허용하는 정책이라 볼 수 있습니다.

 

---

#2. CORS 

CORS는 위에 언급 했듯이 도메인 및 포트가 다른 서버로 요청했을 때 브라우저가 보안 상의 이유로 API접근을 차단하고 브라우저에 두개 이상에 서버와 연결 되는 것을 예외적으로 혀용하는 정책 입니다. 

 

기본적으로 SOP(Same-Origin Policy)정책을 이용해 서로 같은 origin이어야 접근할 수 있도록 만들어져 있습니다. 이때 같은 origin은 프로토콜, 호스트, 포트번호가 모두 같은 경우를 same-origin이라고 합니다. 여기서 프로토콜, 호스트, 포트번호는 같은 서버로 판단하는 기준입니다.

 

---

 

#3. CORS 접근 제어 시나리오

 

접근 제어 시나리오는 대표적으로 3가지가 있습니다. 인증 정보는 나중에 쿠키를 배울 때 자세히 다뤄 보도록 하겠습니다.

 

Simple request : 단순 요청

Preflight request : options method, flight요청

Request with credentials : 인증 정보를 포함한 요청

 

#Simple request

요청 메서드는 GET, HEAD, POST 중 하나여야 합니다.

위와 같은 내용을 제외한 헤더를 사용하면 안됩니다. 

 

만약 Content-Type을 사용하는 경우에는 아래와 값들이 허용이 됩니다.

 

#preflight request

OPTIONS 메서드로 예비요청을 보내 실제 요청이 전송하기전에 안전한지 확인 후 본 요청을 보냅니다.

 

Origin에 대한 정보 뿐만 아니라 자신이 예비 요청 이후 보낼 본 요청에 대한 다른 정보들도 같이 포함 되어 있습니다. (Access-Control-Allow-Origin , Access-Control-Allow-Origin)

 

요청에 Origin과 응답의 Access-Control-Allow-Origin을 브라우저가 비교해 출처를 판단하여 다르면 에러를 발생시키고 접근 가능한 출처라면 본 요청을 보내 서버는 200번대의 성공 코드를 반환합니다.

 

---

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS