Azure Storage에 대한 CORS(Cross-Origin Resource Sharing) 지원

버전 2013-08-15부터 Azure 저장소 서비스는 Blob, 테이블 및 큐 서비스에 대해 CORS(크로스-원본 자원 공유)를 지원합니다. 파일 서비스는 버전 2015-02-21부터 CORS를 지원합니다.

CORS는 특정 도메인에서 실행되는 웹 애플리케이션이 다른 도메인의 자원에 액세스할 수 있도록 하는 HTTP 기능입니다. 웹 브라우저는 웹 페이지가 다른 도메인의 API를 호출할 수 없도록 하는 동일 원본 정책이라는 보안 제한을 구현합니다. CORS는 특정 도메인(원본 도메인)에서 다른 도메인의 API를 호출할 수 있는 안전한 방법을 제공합니다. CORS에 대한 자세한 내용은 CORS 사양을 참조하세요.

Blob 서비스 속성 설정, 파일 서비스 속성 설정, 큐 서비스 속성 설정 및 테이블 서비스 속성 설정을 호출하여 각 Azure Storage 서비스에 대해 개별적으로 CORS 규칙을 설정할 수 있습니다. 서비스에 대해 CORS 규칙을 설정하고 나면 다른 도메인에서 해당 서비스에 대해 수행하는 적절하게 권한이 부여된 요청을 평가하여 지정된 규칙에 따라 해당 요청이 허용되는지 여부를 결정합니다.

CORS 요청 이해

원본 도메인의 CORS 요청은 두 가지 개별 요청으로 구성될 수 있습니다.

• 서비스에서 적용하는 CORS 제한을 쿼리하는 실행 전 요청. 요청 메서드가 GET, HEAD, POST 등의 단순 메서드가 아니면 실행 전 요청을 수행해야 합니다.

• 원하는 자원에 대해 수행될 실제 요청

실행 전 요청

실행 전 요청에서는 계정 소유자가 스토리지 서비스에 대해 설정한 CORS 제한을 쿼리합니다. 웹 브라우저 또는 기타 사용자 에이전트는 요청 헤더, 메서드 및 원본 도메인이 포함된 OPTIONS 요청을 보냅니다. 그러면 스토리지 서비스는 미리 구성된 CORS 규칙 집합에 따라 수행하려는 작업을 평가합니다. 이러한 규칙은 스토리지 리소스에 대한 실제 요청에서 지정할 수 있는 원본 도메인, 요청 메서드 및 요청 헤더를 지정합니다.

서비스에 대해 CORS를 사용하도록 설정했으며 실행 전 요청과 일치하는 CORS 규칙이 있으면 서비스는 상태 코드 200(정상) 응답을 보내며 필수 Access-Control 헤더를 응답에 포함합니다.

서비스에 대해 CORS를 사용하도록 설정하지 않았거나 실행 전 요청과 일치하는 CORS 규칙이 없으면 서비스는 상태 코드 403(사용 권한 없음) 응답을 보냅니다.

OPTIONS 요청에 필수 CORS 헤더(Origin 및 Access-Control-Request-Method 헤더)가 없으면 서비스는 상태 코드 400(잘못된 요청) 응답을 보냅니다.

실행 전 요청은 요청된 리소스가 아닌 서비스(Blob, 파일, 큐 또는 테이블)에 대해 평가됩니다. 요청이 성공하려면 계정 소유자가 적절한 계정 서비스 속성을 설정하여 CORS를 사용하도록 설정해야 합니다.

실제 요청

실행 전 요청이 수락되고 응답이 반환되면 브라우저가 스토리지 리소스에 대한 실제 요청을 디스패치합니다. 실행 전 요청이 거부되면 브라우저는 실제 요청을 즉시 거부합니다.

실제 요청은 스토리지 서비스에 대한 일반 요청으로 처리됩니다. Origin 헤더가 있는 요청은 CORS 요청이며, 서비스에서는 일치하는 CORS 규칙이 있는지를 확인합니다. 일치하는 규칙이 있으면 Access-Control 헤더가 응답에 추가되어 클라이언트로 다시 전송됩니다. 일치하는 규칙이 없으면 CORS Access-Control 헤더가 반환되지 않습니다.

Azure Storage에 CORS 사용

CORS 규칙은 서비스 수준에서 설정되므로 각 서비스(Blob, 파일, 큐 및 테이블)에 대해 CORS를 개별적으로 사용하거나 사용하지 않도록 설정해야 합니다. CORS는 기본적으로 각 서비스에 대해 사용하지 않도록 설정됩니다. CORS를 사용하도록 설정하려면 Blob, 큐 및 테이블 서비스 또는 버전 2015-02-21 또는 파일 서비스에 대해 버전 2013-08-15 이상을 사용하여 적절한 서비스 속성을 설정해야 합니다. 서비스 속성에 CORS 규칙을 추가하여 CORS를 사용하도록 설정합니다. 서비스에 CORS를 사용하거나 사용하지 않도록 설정하는 방법과 CORS 규칙을 설정하는 방법에 대한 자세한 내용은 Blob 서비스 속성 설정, 파일 서비스 속성 설정, 테이블 서비스 속성 설정 및 큐 서비스 속성 설정을 참조하세요.

다음은 작업을 통해 지정된 단일 CORS 규칙의 샘플입니다.Set Service Properties

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://*.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>  
  

아래에는 CORS 규칙에 포함된 각 요소에 대한 설명이 나와 있습니다.

• 허용된 원본: CORS를 통해 스토리지 서비스에 대한 요청을 수행하도록 허용되는 원본 도메인입니다. 원본 도메인에서 요청이 시작됩니다. 이 원본은 사용자가 서비스로 보내는 원본과 대/소문자까지 정확하게 일치해야 합니다.

  지정된 도메인 대신 와일드카드 문자 '*'를 사용하여 모든 원본 도메인이 CORS를 통해 요청할 수 있도록 할 수 있습니다. 하위 도메인 대신 와일드카드 문자를 사용하여 지정된 도메인의 모든 하위 도메인이 CORS를 통해 요청하도록 허용할 수도 있습니다. 위의 예제에서 의 contoso.com 모든 하위 도메인은 CORS를 통해 요청을 수행할 수 있지만 하위 도메인의 fabrikam.com 요청 www 만 CORS를 통해 허용됩니다.

• 허용되는 메서드: 원본 도메인이 CORS 요청에 사용할 수 있는 메서드(HTTP 요청 동사)입니다. 위의 예제에서는 PUT 및 GET 요청만 허용됩니다.

• 허용되는 헤더: 원본 도메인이 CORS 요청에 대해 지정할 수 있는 요청 헤더입니다. 위의 예에서 x-ms-meta-data, x-ms-meta-target 및 x-ms-meta-abc로 시작되는 모든 메타데이터 헤더가 허용됩니다. 와일드카드 문자 '*'는 지정한 접두사로 시작하는 모든 헤더가 허용됨을 나타냅니다.

• 표시되는 헤더: CORS 요청에 대한 응답에 포함하여 전송할 수 있으며 브라우저에서 요청 발급자에 대해 표시할 수 있는 응답 헤더입니다. 위의 예에서 브라우저는 x-ms-meta로 시작되는 헤더를 노출하도록 지시를 받습니다.

• MaxAgeInSeconds: 브라우저가 실행 전 OPTIONS 요청을 캐시해야 하는 최대 시간입니다.

Azure 저장소 서비스에서는 AllowedHeaders 및 ExposedHeaders 요소에 대해 접두사 헤더를 지정할 수 있습니다. 헤더 범주를 허용하려는 경우 해당 범주에 공통 접두사를 지정하면 됩니다. 예를 들어 x-ms-meta*를 접두사 헤더로 지정하면 x-ms-meta로 시작되는 모든 헤더와 일치하는 규칙이 설정됩니다.

CORS 규칙에는 다음 제한이 적용됩니다.

• 스토리지 서비스당 최대 5개의 CORS 규칙(Blob, 파일, 테이블 및 큐)을 지정할 수 있습니다.

• XML 태그를 제외한 요청에 대한 모든 CORS 규칙 설정의 최대 크기는 2KiB를 초과하면 안 됩니다.

• 허용되는 헤더, 표시되는 헤더 또는 허용되는 원본의 길이는 256자를 초과할 수 없습니다.

• 허용되는 헤더와 표시되는 헤더는 다음 헤더 중 하나일 수 있습니다.

  • 리터럴 헤더 x-ms-meta-processed와 같은 정확한 헤더 이름을 입력합니다. 요청에 대해 최대 64개의 리터럴 헤더를 지정할 수 있습니다.
  • 접두사 헤더- x-ms-meta-data*와 같이 헤더의 접두사를 제공합니다. 이러한 방식으로 접두사를 지정하면 지정된 접두사로 시작하는 모든 헤더가 허용되거나 표시됩니다. 요청에 대해 최대 2개의 접두사 헤더를 지정할 수 있습니다.

• 허용되는 헤더 요소에 지정된 메서드(HTTP 동사)는 Azure Storage 서비스 API에서 지원하는 메서드를 따라야 합니다. 지원되는 메서드는 DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS 및 PUT입니다.

CORS 규칙 평가 논리 이해

스토리지 서비스는 실행 전 요청이나 실제 요청을 받으면 해당하는 서비스 속성 설정 작업을 통해 서비스에 대해 설정한 CORS 규칙을 기준으로 하여 해당 요청을 평가합니다. CORS 규칙은 서비스 속성 설정 작업의 요청 본문에 설정된 순서로 평가됩니다.

다음과 같이 CORS 규칙을 평가합니다.

1. 먼저, 요청의 원본 도메인이 AllowedOrigins 요소에 나열된 도메인에 대해 확인됩니다. 원본 도메인이 목록에 포함되어 있거나 와일드카드 문자 '*'를 통해 모든 도메인이 허용되는 경우에는 규칙 평가가 계속 진행됩니다. 원본 도메인이 포함되어 있지 않으면 요청은 실패합니다.

2. 다음으로, 요청의 메서드(또는 HTTP 동사)가 AllowedMethods 요소에 나열된 메서드에 대해 확인됩니다. 메서드가 목록에 포함되어 있으면 규칙 평가가 계속 진행되고, 그렇지 않으면 요청이 실패합니다.

3. 요청의 원본 도메인과 메서드가 규칙과 일치하면 해당 규칙을 선택하여 요청을 처리하며 규칙을 추가로 평가하지 않습니다. 그러나 요청이 성공하려면 요청에서 지정된 모든 헤더가 AllowedHeaders 요소에 나열된 헤더에 대해 확인됩니다. 전송된 헤더가 허용되는 헤더와 일치하지 않으면 요청이 실패합니다.

규칙은 요청 본문에 포함된 순서대로 처리되므로 모범 사례에 따르면 원본과 관련하여 가장 제한적인 규칙을 목록에서 첫 번째로 지정하는 것이 좋습니다. 그러면 해당 규칙이 먼저 평가됩니다. 모든 원본을 허용하는 규칙과 같이 제한 수준이 가장 낮은 규칙은 목록의 맨 끝에 지정합니다.

예제 - CORS 규칙 평가

다음 예제에서는 스토리지 서비스에 대해 CORS 규칙을 설정하는 작업의 요청 본문 중 일부분을 보여 줍니다. 요청 생성에 대한 자세한 내용은 Blob 서비스 속성 설정, 파일 서비스 속성 설정, 큐 서비스 속성 설정 및 테이블 서비스 속성 설정을 참조하세요.

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

다음으로는 아래 CORS 요청을 살펴보세요.

첫 번째 요청은 첫 번째 규칙과 일치합니다. 원본 도메인이 허용되는 도메인과 일치하고, 메서드가 허용되는 메서드와 일치하며, 헤더가 허용되는 헤더와 일치하므로 해당 요청은 성공합니다.

두 번째 요청의 경우 메서드가 허용되는 메서드와 일치하지 않으므로 첫 번째 규칙과 일치하지 않습니다. 그러나 두 번째 규칙과는 일치하므로 요청은 성공합니다.

세 번째 요청은 원본 도메인과 메서드가 두 번째 규칙과 일치하므로 규칙을 추가로 평가하지 않습니다. 그러나 x-ms-client-request-id 헤더가 두 번째 규칙에서 허용되지 않으므로 세 번째 규칙의 의미를 따를 경우 요청이 성공할 수 있음에도 불구하고 요청은 실패합니다.

Vary 헤더 설정 방법 이해

Vary 헤더는 서버에서 요청을 처리하기 위해 선택한 조건에 대해 브라우저나 사용자 에이전트에 알려주는 요청 헤더 필드의 집합으로 구성된 표준 HTTP/1.1 헤더입니다. Vary 헤더는 프록시, 브라우저 및 CDN에서 캐싱에 주로 사용되며, 이 헤더를 통해 응답이 캐시되는 방법이 결정됩니다. 자세한 내용은 Vary 헤더사양을 참조하세요.

브라우저 또는 다른 사용자 에이전트가 CORS 요청에서 응답을 캐시할 때는 원본 도메인이 허용되는 원본으로 캐시됩니다. 캐시가 활성 상태인 동안 두 번째 도메인에서 스토리지 리소스에 대해 같은 요청을 실행하면 사용자 에이전트가 캐시된 원본 도메인을 검색합니다. 일반적인 경우에는 요청이 성공하지만, 이 경우에는 두 번째 도메인이 캐시된 도메인과 일치하지 않으므로 요청이 실패합니다. 경우에 따라 Azure Storage는 헤더를 Vary 로 Origin 설정하여 요청 도메인이 캐시된 원본과 다른 경우 사용자 에이전트가 후속 CORS 요청을 서비스로 보내도록 지시합니다.

Azure Storage는 Vary 다음과 같은 경우 실제 GET/HEAD 요청에 대해 헤더 Origin 를 로 설정합니다.

• 요청 원본이 CORS 규칙에 의해 정의된 허용되는 원본과 정확하게 일치하는 경우. 정확히 일치하기 위해 CORS 규칙에 와일드카드 ' *' 문자가 포함되지 않을 수 있습니다.

• 요청 원본과 일치하는 규칙은 없지만 스토리지 서비스에 대해 CORS를 사용하도록 설정한 경우

GET/HEAD 요청이 모든 원본을 허용하는 CORS 규칙과 일치하는 경우 응답은 모든 원본이 허용됨을 나타내며, 사용자 에이전트 캐시는 해당 캐시가 활성 상태인 동안 모든 원본 도메인에서 수행하는 후속 요청을 허용합니다.

GET/HEAD 이외의 메서드를 사용하는 요청의 경우 이러한 메서드에 대한 응답이 사용자 에이전트에서 캐시되지 않으므로 저장소 서비스는 Vary 헤더를 설정하지 않습니다.

다음 표에는 Azure Storage가 앞에서 설명한 사례를 기준으로 하여 GET/HEAD 요청에 응답하는 방법이 나와 있습니다.

CORS 요청에 대한 청구

계정에 대한 스토리지 서비스에 대해 CORS를 사용하도록 설정한 경우 성공적인 실행 전 요청이 청구됩니다(Blob 서비스 속성 설정, 큐 서비스 속성 설정, 파일 서비스 속성 설정 또는 테이블 서비스 속성 설정). 요금을 최소화하려면 사용자 에이전트가 요청을 캐시하도록 CORS 규칙에서 MaxAgeInSeconds 요소를 큰 값으로 설정하는 것이 좋습니다.

실행 전 요청이 실패하면 요금이 청구되지 않습니다.

추가 정보

W3C 교차 원본 자원 공유 사양