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

교차 출처 리소스 공유(CORS)는 한 도메인에 로드된 클라이언트 웹 애플리케이션이 다른 도메인의 리소스와 상호작용할 수 있는 방법을 정의해요. CORS 지원을 사용하면 Amazon S3로 풍부한 클라이언트 측 웹 애플리케이션을 만들고, Amazon S3 리소스에 대한 교차 출처 접근을 선택적으로 허용할 수 있어요.

출처: 문서

본문

이 섹션은 CORS의 개요를 제공해요. 하위 주제에서는 Amazon S3 콘솔로 CORS를 활성화하는 방법과 Amazon S3 REST API 및 AWS SDK를 이용한 프로그래밍 방식 활성화 방법을 설명해요.

CORS 사용에 대한 예시 시나리오는 다음과 같아요.

시나리오 1 — Amazon S3로 정적 웹사이트 호스팅에서 설명한 대로 website라는 이름의 Amazon S3 버킷에 웹사이트를 호스팅하고 있다고 가정해 볼게요. 사용자는 웹사이트 엔드포인트를 로드해요.

http://website.s3-website.us-east-1.amazonaws.com

이제 이 버킷에 저장된 웹페이지에서 JavaScript를 사용해, 버킷의 Amazon S3 API 엔드포인트 website.s3.us-east-1.amazonaws.com를 대상으로 인증된 GET과 PUT 요청을 보내고 싶다고 해볼게요. 브라우저는 보통 JavaScript가 그런 요청을 보내는 것을 차단하지만, CORS를 사용하면 website.s3-website.us-east-1.amazonaws.com의 교차 출처 요청을 명시적으로 허용하도록 버킷을 구성할 수 있어요.

시나리오 2 — S3 버킷에서 웹 폰트를 호스팅하고 싶다고 가정해 볼게요. 여기서도 브라우저는 웹 폰트를 로드할 때 CORS 확인(사전 확인, preflight check라고도 해요)을 요구해요. 웹 폰트를 호스팅하는 버킷이 어떤 출처에서든 이런 요청을 허용하도록 구성하면 돼요.

Amazon S3는 버킷의 CORS 구성을 어떻게 평가하나요? (How does Amazon S3 evaluate the CORS configuration on a bucket?)

Amazon S3는 브라우저에서 사전 확인 요청을 받으면 버킷의 CORS 구성을 평가하고, 들어오는 브라우저 요청과 일치하는 첫 번째 CORSRule 규칙을 사용해 교차 출처 요청을 활성화해요. 규칙이 일치하려면 다음 조건이 충족되어야 해요.

버킷으로 보내는 CORS 요청의 Origin 헤더가 CORS 구성의 AllowedOrigins 요소에 있는 출처와 일치해야 해요.
버킷으로 보내는 CORS 요청의 Access-Control-Request-Method에 지정된 HTTP 메서드가 CORS 구성의 AllowedMethods 요소에 나열된 메서드와 일치해야 해요.
사전 확인 요청의 Access-Control-Request-Headers 헤더에 나열된 헤더가 CORS 구성의 AllowedHeaders 요소에 있는 헤더와 일치해야 해요.

참고 버킷에서 CORS를 활성화해도 ACL과 정책은 계속 적용돼요.

Object Lambda 액세스 포인트가 CORS를 지원하는 방법 (How Object Lambda Access Point supports CORS)

S3 Object Lambda가 브라우저에서 요청을 받거나 요청에 Origin 헤더가 포함된 경우, S3 Object Lambda는 항상 "AllowedOrigins":"*" 헤더 필드를 추가해요.

CORS 사용에 대한 자세한 내용은 다음 주제를 참고하세요.