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

교차 출처 리소스를 안전하게 공유

Mariko Kosaka
X

브라우저의 동일 출처 정책이 다른 출처의 리소스 읽기를 차단합니다. 이 메커니즘은 악성 사이트가 다른 사이트의 데이터를 읽는 것을 막지만 합법적인 사용도 차단합니다.

최신 웹 앱은 다른 출처에서 리소스를 가져오려고 하는 경우가 많습니다. 예를 들어 다른 도메인에서 JSON 데이터를 검색하거나 다른 사이트의 이미지를 <canvas> 요소로 로드하려고 합니다. 누구나 읽을 수 있는 공개 리소스일 수 있지만 동일 출처 정책으로 인해 사용이 차단됩니다. 개발자는 지금까지 JSONP와 같은 해결 방법을 사용했습니다.

교차 출처 리소스 공유 (CORS)는 이 문제를 표준화된 방식으로 해결합니다. CORS를 사용 설정하면 서버가 브라우저에 추가 출처를 사용할 수 있음을 알립니다.

리소스 요청은 웹에서 어떻게 작동하나요?

요청 및 응답
클라이언트 요청 및 서버 응답을 보여줍니다.

브라우저와 서버는 하이퍼텍스트 전송 프로토콜 (HTTP)을 사용하여 네트워크를 통해 데이터를 교환할 수 있습니다. HTTP는 리소스를 가져오는 데 필요한 정보를 포함하여 요청자와 응답자 간의 통신 규칙을 정의합니다.

HTTP 헤더는 클라이언트와 서버 간의 메시지 교환을 협상하며 액세스를 결정하는 데 사용됩니다. 브라우저의 요청과 서버의 응답 메시지는 모두 헤더와 본문으로 나뉩니다.

메시지 유형 또는 메시지 인코딩과 같은 메시지 관련 정보입니다. 헤더에는 키-값 쌍으로 표현되는 다양한 정보가 포함될 수 있습니다. 요청 헤더와 응답 헤더는 서로 다른 정보를 포함합니다.

샘플 요청 헤더

Accept: text/html
Cookie: Version=1

이 헤더는 "응답으로 HTML을 받고 싶습니다. 여기 쿠키가 있어요."

샘플 응답 헤더

Content-Encoding: gzip
Cache-Control: no-store

이 헤더는 '이 응답의 데이터는 gzip으로 인코딩되어 있습니다. 캐시하지 마세요.'

본체

메시지 자체입니다. 일반 텍스트, 이미지 바이너리, JSON, HTML 또는 기타 여러 형식일 수 있습니다.

CORS 작동 방식

동일 출처 정책은 교차 출처 요청을 차단하도록 브라우저에 지시합니다. 다른 출처의 공개 리소스가 필요한 경우 리소스 제공 서버는 요청을 전송하는 출처에서 리소스에 액세스할 수 있다고 브라우저에 알립니다. 브라우저가 이 정보를 기억하여 해당 리소스에 대해 교차 출처 리소스 공유를 허용합니다.

1단계: 클라이언트 (브라우저) 요청

브라우저가 교차 출처 요청을 하면 브라우저는 현재 출처 (스키마, 호스트, 포트)가 있는 Origin 헤더를 추가합니다.

2단계: 서버 응답

서버는 이 헤더를 보고 액세스를 허용하려고 할 때 요청 출처를 지정하는 Access-Control-Allow-Origin 헤더를 응답에 추가합니다 (모든 출처를 허용하려면 *).

3단계: 브라우저에서 응답 수신

브라우저는 적절한 Access-Control-Allow-Origin 헤더와 함께 이 응답을 확인하면 응답 데이터를 클라이언트 사이트와 공유합니다.

CORS와 사용자 인증 정보 공유

개인 정보 보호를 위해 CORS는 일반적으로 요청자가 식별되지 않는 익명 요청에 사용됩니다. 발신자를 식별할 수 있는 CORS를 사용할 때 쿠키를 전송하려면 요청과 응답에 헤더를 추가해야 합니다.

요청

다음 예시와 같이 가져오기 옵션에 credentials: 'include'를 추가합니다. 여기에는 다음과 같이 요청과 함께 쿠키가 포함됩니다.

fetch('https://example.com', {
  mode: 'cors',
  credentials: 'include'
})

응답

Access-Control-Allow-Origin는 특정 출처 (*를 사용한 와일드 카드 없음)로 설정해야 하고 Access-Control-Allow-Credentials는 true로 설정해야 합니다.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

복잡한 HTTP 호출을 위한 프리플라이트 요청

웹 앱에서 복잡한 HTTP 요청을 수행하면 브라우저는 요청 체인 시작 부분에 실행 전 요청을 추가합니다.

CORS 사양은 다음과 같이 복잡한 요청을 정의합니다.

  • GET, POST, HEAD 이외의 메서드를 사용하는 요청입니다.
  • Accept, Accept-Language, Content-Language 이외의 헤더가 포함된 요청.
  • application/x-www-form-urlencoded, multipart/form-data, text/plain 이외의 Content-Type 헤더가 있는 요청

브라우저는 필요한 프리플라이트 요청을 자동으로 만들고 실제 요청 메시지 전에 전송합니다. 실행 전 요청은 다음 예시와 같이 OPTIONS 요청입니다.

OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE

서버 측에서 요청을 수신하는 앱은 애플리케이션이 이 출처에서 허용하는 메서드에 관한 정보로 프리플라이트 요청에 응답합니다.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

서버 응답에는 실행 전 결과를 캐시하는 기간(초)을 지정하는 Access-Control-Max-Age 헤더가 포함될 수도 있습니다. 이렇게 하면 클라이언트가 프리플라이트 요청을 반복하지 않고도 복잡한 요청을 여러 개 보낼 수 있습니다.