CORS는 도대체 뭘까..?

1.Cross-Origin Resource Sharing (CORS)

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

CORS를 이해하기 위해선 SOP에 대한 이해가 선행되야 한다.

SOP란?

Same-Origin policy (SOP)

다른 출처의 리소스를 사용하는 것을 제한하는 보안 방식으로, CORS 에러를 일으키는 정책이다.

The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin. - mdn

한 출처에서 로드된 스크립트나 문서가 다른 출처에서 온 리소스와의 상호작용 할 수 있는 방법을 제한한 메커니즘

즉, 웹 브라우저에서 동작하는 프로그램은 로딩된 위치에 있는 리소스만 접근 할 수 있다.

더 쉬운말로는..

→ 같은 출처에서만 리소스를 공유할 수 있다

→ A라는 출처에서 온 문서가 B출처에서 가져온 리소스와 상호작용을 차단하는 보안 정책

SOP는 왜 있을까?

SOP 정책은 보안을 위협하는 문서를 격리시켜, 보안 위협으로부터 보호할 수 있다.

• 만약 해당 정책이 없다면?이런 상황을 사전에 방지하기 위해 sop가 존재한다.
• 사용자가 악성 페이지에 접속해서 악의적인 js가 실행된다면, 사용자가 모르는 사이에 임의의 요청을 보내고
  응답값을 해커가 탈취해갈 수 있다.

trust zone

• 그러나 두 도메인이 신뢰도가 높은 영역(회사 인트라넷 등,,)에 있는 경우 SOP 제한이 적용되지 않는다.

출처 정책에 대한 처리

• 만약 웹 사이트 http://sitea.com에서 자바스크립트를 로딩 한 다음에 이 스크립트에서, http://api.my.com을 호출한다면 동일 출처 정책에 의해서 호출한다면 호출 에러가 발생한다.
• 이를 해결하는 방법으로는 인프라 측면에서 프록시를 사용하는 방법이나 JSONP와 CORS(Cross Origin Resource Sharing)이라는 방법이 있다.

리소스 요청은 출처가 다르더라도 허용하기로 결정, 그 중 하나가 CORS 정책을 지킨 리소스 요청이다.

2. cross-origin HTTP requests

웹 애플리케이션에서 요청할 리소스가 자신의 출처와 다를 때 사용한다.

브라우저에서 보안상의 이유로 cross-origin HTTP requests를 제한한다.

(XMLHttpRequest와 Fetch API는 동일 출처 정책(same-origin policy)을 따른다.)

→ cors를 사용해 cross-origin HTTP requests의 위험을 완화한다.

---

3. origin?

여기서 말하는 Origin은 출처를 뜻한다.

• 두개의 URL이 존재할 때 프로토콜, 포트(지정된 경우), 호스트가 동일한 경우 두 URL의 Origin이 같다고 판단한다.

[https://google.com](https://google.com) 와 같은 URL을 예시로 들어보자.

• https:// → Protocol
• [google.com](http://google.com) → Host

출처는 Protocol과 Host를 포함한 포트 번호까지 모두 합친것을 의미한다.
즉, 서버의 위치를 찾아가기 위해 필요한 요소를 합쳐놓은 것을 출처라 부른다.

• 참고로 출처 내의 포트번호가 보이지 않는건 생략되서다.
  • HTTP, HTTPS는 프로토콜의 기본 포트 번호가 정해져있기 때문이다.
    • HTTP URL 참고자료
    • RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1

우리가 다른 출처로 리소스를 요청한다면 SOP 정책을 위반한 것이 되고, 거기다가 SOP의 예외 조항인 CORS 정책까지 지키지 않는다면 아예 다른 출처의 리소스를 사용할 수 없게 된다.

4. 같은 출처와 다른 출처의 구분

사실 두 개의 출처가 서로 같다고 판단하는 로직 자체는 굉장히 간단한데, 두 URL의 구성 요소 중 Scheme, Host, Port, 이 3가지만 동일하면 된다.

https://willy4202.github.io:80라는 출처를 예로 들면 https:// 이라는 스킴에
**willy4202.github.io** 라는 호스트를 가지고 :80번 포트를 사용하고 있다는 것만 같다면 나머지는 전부 다르더라도 같은 출처로 인정이 된다는 것이다.

참고로

, ie의 경우에는 출처 비교시 포트 번호를 무시하는 브라우저라고 한다.

여기서 알 수 있는건, 출처를 비교하는 로직이 서버가 아닌 브라우저에 구현되어 있다는 것이다.

• CORS 정책을 위반하는 요청을 한다면 서버는 정상적으로 응답하겠지만, 브라우저가 짤라내는 형태
• 서버간 통신을 할때는, 이 정책이 적용되지 않음

5. CORS는 어떻게 동작하나?

기본적으로 웹 어플리케이션이 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아보낸다.

이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin이라는 값에
“이 리소스를 접근하는 것이 허용된 출처”를 내려주고,

이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정한다.

5-1. Preflight request - 사전 전달

프리플라이트(Preflight) 방식은 일반적으로 우리가 웹 어플리케이션을 개발할 때 가장 마주치는 시나리오이다. 브라우저는 요청을 한번에 보내지 않고 예비 요청과 본 요청으로 나누어서 서버로 전송한다.

이때 브라우저가 보내는 예비 요청을 Preflight라고 부른다. HTTP 메소드 중 OPTIONS 메소드가 사용된다. 예비 요청의 역할은 본 요청을 보내기 전에 브라우저 스스로 이 요청을 보내는 것이 안전한지 확인하는 것이다.
cross-origin 요청은 유저 데이터에 영향을 줄 수 있기 때문에 이 같은 과정을 거치는 것이다.

5-2. Simple Request

단순 요청은 예비 요청을 보내지 않고 바로 서버에게 본 요청부터 때려박은 후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.

즉, 프리플라이트와 단순 요청 시나리오는 전반적인 로직 자체는 같되, 예비 요청의 존재 유무만 다르다.

5-3. Credentialed Request

CORS의 기본적인 방식이라기 보다는 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법이다.기본적으로 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다. 이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션이다.