교차 출처 리소스 공유 (CORS)

등장 배경

동일 출처 정책 (SOP: Same-Origin Policy)

원래 도메인이 다르면 요청을 주고받을 수 없게 하려는 게 웹브라우저의 주요 정책이었다. 동일출처정책은 어떤 출처(origin)에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식이다, 출처가 같다는 것은 두 URL의 프로토콜, 호스트, 포트 세 개가 같다는 것을 말한다.

크로스 도메인 (Cross Domain) 이슈

• 그러나 점점 웹사이트에서 할 수 있는 일이 많아지면서 문제가 생겼다. Ajax가 나오고 Open API가 활발해지면서 웹이 단순 문서가 아니라 어플리케이션이 되었다. 이때 자바스크립트(XMLHttpRequest)로 다른 웹페이지에 접근할 때 다른 출처의 페이지에도 접근해야 할 필요성이 생겼다.

• 즉, SOP를 우회해서 서로 다른 도메인 간에 통신을 할 수 있게 해줄 무언가가 필요하게 되었다. 따라서 JSONP, Reverse Proxy, Flash Socket와 우회 방법이 생겨나게 되었다.

CORS의 등장

• 웹브라우저 입장에서는 이 우회로를 그냥 두기에는 보안상의 문제가 커지고, 막자니 CORS에 대한 수요가 너무 많았다. 따라서 크로스 도메인 이슈를 해결할 표준의 필요성이 대두되었다.

• 이에 W3C에서 권장사항으로 CORS 사양을 발표하게 되었다.
• 현재 활발하게 유지 관리되는 사양은 WHATWG의 Fetch Living Standard

CORS(Cross-Origin Resource Sharing)란?

• 추가 HTTP 헤더를 사용하여 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려 주는 체제이다.
• 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차출처 HTTP 요청을 실행한다.
• CORS 체제는 브라우저와 서버 간 안전한 교차 출처 요청 및 데이터 전송을 지원한다.
• SOP를 따르는 XMLHttpRequest와 Fetch API를 사용하는 웹 애플리케이션이 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 리턴해야 한다.
• CORS를 사용하는 요청
  • XMLHttpRequest, Fetch API 호출
  • 웹 폰트
  • WebGL 텍스처
  • drawImage()를 사용해 그린 이미지/비디오 프레임
  • 이미지로부터 추출하는 CSS Shapes
  • 이 이외의 요청은 허락하지 않는다.

CORS 요청 종류

간단한 요청(Simple Request)

• 기존 데이터에 부작용을 일으키지 않는 요청
• CORS 사전 요청을 발생시키지 않는 요청
• 조건
  • GET, HEAD, POST 중 한 가지 방식을 사용한다.
  • Custom Header 불포함
    • 예외) Fetch 명세에서 CORS-safelisted request-header로 정의한 헤더의 경우 수동으로 설정할 수 있다.
  • POST일 경우 Content-Type이 아래 셋 중 하나를 만족
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain
• 모든 도메인 요청 리소스 접근 허용: Access-Control-Allow-Origin: *
• 특정 도메인의 요청만 리소스 접근 허용: Access-Control-Allow-Origin: 허락된도메인명

사전 요청(Preflighted Request)

• 본 요청을 보내기 전에 사전 요청을 보내서 서버가 이에 응답이 가능한 지 확인하는 방법이다. Cross-site요청은 유저 데이터에 영향을 줄 수 있기 때문에 미리 전송(preflighted)하여 실제 요청이 전송하기에 안전한 지 확인할 수 있다.
• 사전 요청을 보내는 경우
  • GET, HEAD, POST 이외의 요청
  • Custom Header 포함
  • POST 요청일 경우 Content-Type이 아래 셋을 만족하지 않을 때
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain
• 사전 요청 과정
  • 1. 동일한 URL에 OPTIONS method로 요청(Preflight)

    • OPTIONS : 서버에서 추가 정보를 판별하는 데 사용하는 HTTP/1.1 메서드이다. safe메서드이기 때문에, 리소스를 변경하는 데 사용할 수 없다.

    • OPTIONS 요청과 함께 두 개의 다른 요청 헤더가 전송된다.

      • Access-Control-Request-Method: POST
      • Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • 1. 요청에 대해 서버에서는 허용되는 method, 허용하는 헤더, 쿠키 허용 여부를 응답
  • 1. 서버가 요청을 허용한다면 본 요청을 보낸다.

preflighted request 이후 리다이렉트를 지원하지 않는 브라우저 대처방안

• preflight 리다이렉트를 방지하기 위해 서버측 동작 변경
• preflight를 발생시키지 않는 simple request가 되도록 요청 변경

인증정보를 포함한 요청(Request with Credentials)

• 기본적으로 cross-sitew XMLHttpRequest나 Fetch호출에서 브라우저는 자격 증며에을 보내지 않는다. XMLHttpRequest 객체나 Request 생성자가 호출될 때 특정한 플래그를 설정해야 한다.

1
2
3
4
5
6
7
8
9
10
11
12

const invocation = new XMLHttpRequest();
const url = 'http://bar.other/resources/credentialed-content/';
    
function callOtherDomain() {
  if (invocation) {
    invocation.open('GET', url, true);
    // 플래그
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}

• 요청에 쿠키를 포함하고 싶다면 XMLHttpRequest 객체의 withCredential 프로퍼티 값을 true로 설정한다.

• 허용한다면 서버 측은 Access-Control-Allow-Credentials 응답 헤더를 true로 설정한다.

• credentials request에 응답할 때는 Access-Control-Allow-Origin헤더에 반드시 값을 지정해야 한다. 와일드 카드(*)를 사용하면 안 된다. 와일드 카드일 경우 요청이 실해한다.

HTTP 응답 헤더

• Access-Control-Allow-Origin: 단일 출처를 지정하여 브라우저가 해당 출처가 리소스에 접근하도록 허용된다. credentials request 없는 경우 와일드 카드를 사용해 브라우저의 origin에 상관 없이 모든 리소스에 접근하도록 허용할 수 있다.
• Access-Control-Expose-Headers: 브라우저가 접근할 수 있는 헤더를 서버의 화이트리스트엘 추가
• Access-Control-Max-Age: preflight request 요청 결과를 캐시할 수 있는 시간 지정
• Access-Control-Allow-Credentials: credentials request 허용 여부 지정
• Access-Control-Allow-Methods: 리소스에 접근할 때 허용되는 메서드 지정
• Access-Control-Allow-Headers: preflight request 요청 시 사용할 수 있는 HTTP 헤더 지정

HTTP 요청 헤더

• Origin: cross-site 접근 요청 또는 preflight request의 출처로, 접근 제어 요청 시 항상 전송된다.
  • Origin: 요청시작된서버URL
• Access-Control-Request-Method: 실제 요청에서 어떤 HTTP 메서드를 사용할 지 서버에게 알려주기 위해 preflight request할 때 사용된다.
• Access-Control-Request-Headers: 실제 요청에서 어떤 HTTP 헤더를 사용할 지 서버에게 알려주기 위해 preflight request할 때 사용된다.

cross-site XMLHttpRequest 기능을 사용하는 개발자는 프로그래밍 방식으로 cross-origin 공유 요청 헤더를 설정할 필요 없다.

참조

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
2. https://youtu.be/yTzAjidyyqs
3. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing