CORS(Cross-Origin Resource Sharing) - AWS SDK for JavaScript
CORS 작동 방식CORS 구성이 필요함Amazon S3 버킷에 맞는 CORS 구성CORS 구성의 예

곧 AWS SDK for JavaScript(v2)에 대한 지원이 종료될 예정임을 알려드립니다. AWS SDK for JavaScript v3로 마이그레이션하실 것을 권장합니다. 마이그레이션 날짜, 추가 세부 정보 및 방법에 대한 자세한 내용은 링크된 공지 사항을 참조하세요.

CORS(Cross-Origin Resource Sharing)

CORS(Cross-origin 리소스 공유)는 최신 웹 브라우저의 보안 기능입니다. 이 기능을 사용하면 웹 브라우저가 어떤 도메인이 외부 웹 사이트 또는 서비스를 요청할 수 있을지 협상할 수 있습니다. 대부분의 리소스 요청이 외부 도메인(예: 웹 서비스용 엔드포인트)으로 전송되기 때문에 AWS SDK for JavaScript를 사용해 브라우저 애플리케이션을 개발하는 경우 CORS는 중요한 고려 대상입니다. JavaScript 환경에서 CORS 보안을 적용하는 경우 이 서비스와 함께 CORS를 구성해야 합니다.

CORS는 다음을 기준으로 cross-origin 요청 시 리소스 공유 여부를 결정합니다.

  • 요청을 수행한 특정 도메인

  • 수행 중인 HTTP 요청 유형(GET, PUT, POST, DELETE 등)

CORS 작동 방식

가장 간단한 경우 브라우저 스크립트는 다른 도메인 내 서버의 리소스에 대해 GET 요청을 수행합니다. 요청이 GET 요청을 제출하도록 승인된 도메인에서 전송된 경우 해당 서버의 CORS 구성에 따라 cross-origin 서버는 요청된 리소스를 반환하여 응답합니다.

요청하는 도메인 또는 HTTP 요청 유형이 승인되지 않은 경우에는 요청이 거부됩니다. 그러나 CORS는 요청을 실제로 제출하기 전에 요청을 사전에 보낼 수 있습니다. 이 경우 preflight 요청은 OPTIONS 액세스 요청 작업을 전송하는 방식으로 이루어집니다. cross-origin 서버의 CORS 구성이 요청하는 도메인에 대한 액세스 권한을 부여하는 경우 서버에서는 요청하는 도메인이 요청한 리소스에 대해 수행 가능한 HTTP 요청 유형을 모두 나열하는 preflight 응답으로 회신합니다.

CORS 요청의 프로세스 흐름

CORS 구성이 필요함

Amazon S3 버킷에서 작업을 수행하려면 먼저 해당 버킷에 CORS를 구성해야 합니다. 일부 JavaScript 환경에서는 CORS를 적용할 수 없기 때문에 CORS 구성이 불필요할 수 있습니다. 예를 들어 Amazon S3 버킷에서 애플리케이션을 호스팅하고 *.s3.amazonaws.com 또는 일부 다른 특정 엔드포인트에서 리소스에 액세스하는 경우에는 요청이 외부 도메인에 액세스하지 않습니다. 따라서 이 구성에는 CORS가 필요하지 않습니다. 이 경우에도 CORS는 Amazon S3 이외의 서비스에는 여전히 사용됩니다.

Amazon S3 버킷에 맞는 CORS 구성

Amazon S3 콘솔에서 CORS를 사용하도록 Amazon S3 버킷을 구성할 수 있습니다.

  1. Amazon S3 콘솔에서 수정할 버킷을 선택합니다.

  2. 권한 탭을 선택하고 아래로 스크롤하여 CORS(Cross-origin resource sharing) 패널로 이동합니다.

    버킷의 CORS 구성 설정을 위한 Amazon S3의 CORS 구성 편집기

  3. 수정을 선택하고 CORS 구성 편집기에 CORS 구성을 입력한 다음 저장을 선택합니다.

CORS 구성은 <CORSRule> 내에 일련의 규칙이 포함된 XML 파일입니다. 구성에는 규칙이 최대 100개까지 있을 수 있습니다. 규칙은 다음 태그 중 하나로 정의합니다.

  • <AllowedOrigin>: 교차 도메인 요청을 수행하도록 허용하는 도메인 오리진을 지정합니다.

  • <AllowedMethod>: 교차 도메인 요청에서 허용하는 요청 유형(GET, PUT, POST, DELETE, HEAD)을 지정합니다.

  • <AllowedHeader>: preflight 요청에서 허용되는 헤더를 지정합니다.

구성의 예는 Amazon Simple Storage Service 사용 설명서의 버킷 CORS 구성 방법 섹션을 참조하세요.

CORS 구성의 예

<AllowedOrigin>의 범위를 웹 사이트의 도메인으로 지정하는 것이 좋긴 하지만 다음 CORS 구성 샘플을 사용하면 사용자는 example.org 도메인에서 버킷 내 객체를 보거나, 추가 또는 제거하거나, 업데이트할 수 있습니다. 모든 도메인을 허용하려면 "*"를 지정할 수 있습니다.

중요

새 S3 콘솔에서 CORS 구성은 JSON이어야 합니다.

XML
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <CORSRule>
    <AllowedOrigin>https://example.org</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <ExposeHeader>x-amz-meta-custom-header</ExposeHeader>
  </CORSRule>
</CORSConfiguration>
JSON
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "HEAD",
            "GET",
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "https://www.example.org"
        ],
        "ExposeHeaders": [
             "ETag",
             "x-amz-meta-custom-header"]
    }
]

이 구성은 사용자가 버킷에 대해 작업을 수행하도록 허용하지 않고, 브라우저의 보안 모델이 Amazon S3에 대한 요청을 허용하도록 합니다. 권한은 버킷 권한 또는 IAM 역할 권한을 통해 구성해야 합니다.

ExposeHeader를 사용하면 SDK가 Amazon S3에서 반환된 응답 헤더를 읽도록 할 수 있습니다. 예를 들어, PUT 또는 멀티파트 업로드에서 ETag 헤더를 읽으려면 이전 예제에서처럼 구성에 ExposeHeader 태그를 포함해야 합니다. SDK는 CORS 구성을 통해 노출된 헤더에만 액세스할 수 있습니다. 객체에 대해 메타데이터를 설정한 경우 값은 접두사 x-amz-meta-가 붙은 헤더(예: x-amz-meta-my-custom-header)로 반환되며 동일한 방식으로 노출되어야 합니다.