Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

Mariko Kosaka

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

최신 웹 앱은 다른 출처의 리소스를 가져오려는 경우가 많습니다. 예를 들어 다른 도메인에서 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를 사용할 때 발신자를 식별할 수 있는 쿠키를 보내려면 요청 및 응답에 추가 헤더를 추가해야 합니다.

요청

다음 예와 같이 가져오기 옵션에 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 헤더도 포함될 수 있습니다. 이렇게 하면 클라이언트가 프리플라이트 요청을 반복할 필요 없이 여러 복잡한 요청을 보낼 수 있습니다.