CORS 문제 해결

다음 주제들은 S3와 관련된 일반적인 CORS 문제를 해결하는 데 도움이 돼요.

출처: 문서

본문

403 Forbidden 오류: 이 버킷에 CORS가 활성화되지 않음 (403 Forbidden error: CORS is not enabled for this bucket)

교차 출처 요청이 Amazon S3로 전송되었는데 S3 버킷에 CORS가 구성되어 있지 않으면 다음 403 Forbidden 오류가 발생해요.

오류: HTTP/1.1 403 Forbidden CORS Response: CORS is not enabled for this bucket.

CORS 구성은 버킷에 접근하도록 허용할 출처, 각 출처에 대해 지원할 작업(HTTP 메서드), 기타 작업별 정보를 식별하는 규칙이 담긴 문서 또는 정책이에요. Amazon S3 콘솔, AWS SDK, REST API로 S3에서 CORS를 구성하는 방법을 참고하세요. CORS에 대한 자세한 내용과 CORS 구성 예시는 CORS 요소를 참고하세요.

403 Forbidden 오류: 이 CORS 요청은 허용되지 않음 (403 Forbidden error: This CORS request is not allowed)

CORS 구성의 CORS 규칙이 요청의 데이터와 일치하지 않으면 다음 403 Forbidden 오류를 받게 돼요.

오류: HTTP/1.1 403 Forbidden CORS Response: This CORS request is not allowed.

이 403 Forbidden 오류는 여러 이유로 발생할 수 있어요.

출처가 허용되지 않음.
메서드가 허용되지 않음.
요청된 헤더가 허용되지 않음.

Amazon S3가 받는 각 요청에 대해 CORS 구성에 요청의 데이터와 일치하는 CORS 규칙이 있어야 해요.

출처가 허용되지 않음 (Origin is not allowed)

버킷으로 보내는 CORS 요청의 Origin 헤더는 CORS 구성의 AllowedOrigins 요소에 있는 출처와 일치해야 해요. AllowedOrigins 요소의 와일드카드 문자("*")는 모든 HTTP 메서드와 일치해요. AllowedOrigins 요소를 업데이트하는 방법에 대한 자세한 내용은 교차 출처 리소스 공유(CORS) 구성을 참고하세요.

예를 들어 AllowedOrigins 요소에 http://www.example1.com 도메인만 포함되어 있다면, http://www.example2.com 도메인에서 보낸 CORS 요청은 403 Forbidden 오류를 받게 돼요.

다음 예시는 AllowedOrigins 요소에 http://www.example1.com 도메인이 포함된 CORS 구성의 일부를 보여줘요.

"AllowedOrigins":[
   "http://www.example1.com"
]

http://www.example2.com 도메인에서 보낸 CORS 요청이 성공하려면 http://www.example2.com 도메인이 CORS 구성의 AllowedOrigins 요소에 포함되어야 해요.

"AllowedOrigins":[
   "http://www.example1.com"
   "http://www.example2.com"
]

메서드가 허용되지 않음 (Methods are not allowed)

버킷으로 보내는 CORS 요청의 Access-Control-Request-Method에 지정된 HTTP 메서드는 CORS 구성의 AllowedMethods 요소에 나열된 메서드와 일치해야 해요. AllowedMethods의 와일드카드 문자("*")는 모든 HTTP 메서드와 일치해요. AllowedOrigins 요소를 업데이트하는 방법에 대한 자세한 내용은 교차 출처 리소스 공유(CORS) 구성을 참고하세요.

CORS 구성에서 AllowedMethods 요소에는 다음 메서드를 지정할 수 있어요.

GET
PUT
POST
DELETE
HEAD

다음 예시는 AllowedMethods 요소에 GET 메서드가 포함된 CORS 구성의 일부를 보여줘요. GET 메서드를 포함한 요청만 성공해요.

"AllowedMethods":[
   "GET"
]

CORS 요청에 HTTP 메서드(예: PUT)가 사용되었거나 버킷에 대한 사전 확인 CORS 요청에 포함되었는데 메서드가 CORS 구성에 없다면, 그 요청은 403 Forbidden 오류로 이어져요. 이 CORS 요청이나 CORS 사전 확인 요청을 허용하려면 CORS 구성에 PUT 메서드를 추가해야 해요.

"AllowedMethods":[
   "GET"
   "PUT"
]

요청된 헤더가 허용되지 않음 (Requested headers are not allowed)

사전 확인 요청의 Access-Control-Request-Headers 헤더에 나열된 헤더는 CORS 구성의 AllowedHeaders 요소에 있는 헤더와 일치해야 해요. Amazon S3에 대한 요청에 사용할 수 있는 일반적인 헤더 목록은 Common Request Headers를 참고하세요. AllowedHeaders 요소를 업데이트하는 방법에 대한 자세한 내용은 교차 출처 리소스 공유(CORS) 구성을 참고하세요.

다음 예시는 AllowedHeaders 요소에 Authorization 헤더가 포함된 CORS 구성의 일부를 보여줘요. Authorization 헤더에 대한 요청만 성공해요.

"AllowedHeaders":  [
    "Authorization"
]

헤더(예: Content-MD5)가 CORS 요청에 포함되었는데 CORS 구성에 그 헤더가 없다면, 그 요청은 403 Forbidden 오류로 이어져요. 이 CORS 요청을 허용하려면 CORS 구성에 Content-MD5 헤더를 추가해야 해요. 버킷으로 보내는 CORS 요청에 Authorization과 Content-MD5 헤더를 모두 전달하고 싶다면 CORS 구성의 AllowedHeaders 요소에 두 헤더가 모두 포함되어 있는지 확인해요.

"AllowedHeaders":  [
    "Authorization"
    "Content-MD5"
]

CORS 응답에서 헤더를 찾을 수 없음 (Headers not found in CORS response)

CORS 구성의 ExposeHeaders 요소는 CORS 요청에 대한 응답으로 브라우저에서 실행되는 스크립트와 애플리케이션에 접근할 수 있도록 만들 응답 헤더를 식별해요.

S3 버킷에 저장된 객체에 사용자 정의 메타데이터(예: x-amz-meta-custom-header)가 응답 데이터와 함께 있다면, 이 사용자 정의 헤더는 클라이언트 측 JavaScript 코드에서 접근하려는 추가 메타데이터나 정보를 담을 수 있어요. 하지만 기본적으로 브라우저는 보안상의 이유로 사용자 정의 헤더 접근을 차단해요. 클라이언트 측 JavaScript가 사용자 정의 헤더에 접근하도록 허용하려면 CORS 구성에 그 헤더를 포함해야 해요.

아래 예시에서 x-amz-meta-custom-header1 헤더는 ExposeHeaders 요소에 포함되어 있어요. x-amz-meta-custom-header2는 ExposeHeaders 요소에 포함되지 않아 CORS 구성에서 빠져 있어요. 응답에서는 ExposeHeaders 요소에 포함된 값만 반환돼요. 요청이 Access-Control-Expose-Headers 헤더에 x-amz-meta-custom-header2 헤더를 포함했다면, 응답은 여전히 200 OK를 반환해요. 하지만 예를 들어 x-amz-meta-custom-header 같은 허용된 헤더만 응답에 반환되어 표시돼요.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1"
]

모든 헤더가 응답에 나타나도록 하려면 아래처럼 CORS 구성의 ExposeHeaders 요소에 모든 허용 헤더를 추가해요.

"ExposeHeaders":  [
    "x-amz-meta-custom-header1",
    "x-amz-meta-custom-header2"
]

S3 프록시 통합의 CORS 고려 사항 (Considerations of CORS on S3 proxy integrations)

오류가 발생했고 S3 버킷의 CORS 구성을 이미 확인했으며, Amazon CloudFront 같은 프록시로 교차 출처 요청이 전송된다면 다음을 시도해 보세요.

HTTP 요청에 OPTIONS 메서드를 허용하도록 설정을 구성해요.
다음 헤더를 포워드하도록 프록시를 구성해요: Origin, Access-Control-Request-Headers, Access-Control-Request-Method.
프록시 설정에 오리진 헤더를 캐시 키에 포함하도록 구성해요. 이는 캐시 키에 오리진 헤더를 포함하지 않는 캐싱 프록시가, 서로 다른 출처에 대해 적절한 CORS 헤더를 포함하지 않는 캐시된 응답을 제공할 수 있기 때문에 중요해요.

일부 프록시는 CORS 요청을 위한 미리 정의된 기능을 제공해요. 예를 들어 CloudFront에서는 출처가 Amazon S3 버킷일 때 교차 출처 리소스 공유(CORS) 요청을 활성화하는 헤더를 포함하는 정책을 구성할 수 있어요.

이 정책은 다음 설정을 가져요.

오리진 요청에 포함된 헤더: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
오리진 요청에 포함된 쿠키: 없음
오리진 요청에 포함된 쿼리 문자열: 없음

자세한 내용은 CloudFront Developer Guide의 정책으로 오리진 요청 제어와 관리형 오리진 요청 정책 사용을 참고하세요.