교차 출처 리소스 공유(CORS)는 출처가 다른 리소스 간의 상호작용을 허용합니다. 일반적으로 이러한 상호작용은 악의적인 행동을 방지하기 위해 금지되어 있습니다. 이 페이지를 통해 Cloud Storage 버킷에서 CORS 구성을 설정하는 방법과 버킷에서 설정된 CORS 구성을 보는 방법을 알아봅니다. 버킷의 기존 구성을 사용 중지하는 구성을 비롯한 CORS 구성 예시는 CORS 구성 예시를 참조하세요.
버킷의 CORS 구성 설정
버킷이 수락할 수 있는 요청 유형을 식별하는 HTTP 메서드 및 출처 도메인과 같은 정보를 지정하여 버킷에 CORS 구성을 설정합니다.
버킷에 CORS 구성을 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud 콘솔을 사용하여 CORS를 관리할 수 없습니다. 대신 gcloud CLI를 사용하세요.
명령줄
적용하려는 CORS 구성을 사용해서 JSON 파일을 만듭니다. 샘플 JSON 파일은 구성 예시를 참조하세요.
gcloud storage buckets update
명령어를--cors-file
플래그와 함께 사용합니다.gcloud storage buckets update gs://BUCKET_NAME --cors-file=CORS_CONFIG_FILE
각 항목의 의미는 다음과 같습니다.
BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.CORS_CONFIG_FILE
은 1단계에서 만든 JSON 파일의 경로입니다.
클라이언트 라이브러리
C++
자세한 내용은 Cloud Storage C++ API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
C#
자세한 내용은 Cloud Storage C# API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
Go
자세한 내용은 Cloud Storage Go API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
Java
자세한 내용은 Cloud Storage Java API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
Node.js
자세한 내용은 Cloud Storage Node.js API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
PHP
자세한 내용은 Cloud Storage PHP API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
Python
자세한 내용은 Cloud Storage Python API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
Ruby
자세한 내용은 Cloud Storage Ruby API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
REST API
JSON API
Authorization
헤더에 대한 액세스 토큰을 생성하려면 gcloud CLI가 설치 및 초기화되어 있어야 합니다.또는 OAuth 2.0 Playground를 사용하여 액세스 토큰을 만들고
Authorization
헤더에 포함할 수 있습니다.적용하려는 CORS 구성을 사용해서 JSON 파일을 만듭니다. 샘플 JSON 파일은 구성 예시를 참조하세요.
cURL
을 사용하여PATCH
버킷 요청으로 JSON API를 호출합니다.curl --request PATCH \ 'https://storage.googleapis.com/storage/v1/b/BUCKET_NAME?fields=cors' \ --header 'Authorization: Bearer $(gcloud auth print-access-token)' \ --header 'Content-Type: application/json' \ --data-binary @CORS_CONFIG_FILE
각 항목의 의미는 다음과 같습니다.
BUCKET_NAME
은 버킷의 이름입니다. 예를 들면my-bucket
입니다.CORS_CONFIG_FILE
은 2단계에서 만든 JSON 파일의 경로입니다.
XML API
Authorization
헤더에 대한 액세스 토큰을 생성하려면 gcloud CLI가 설치 및 초기화되어 있어야 합니다.또는 OAuth 2.0 Playground를 사용하여 액세스 토큰을 만들고
Authorization
헤더에 포함할 수 있습니다.범위가
?cors
인PUT Bucket
요청으로 XML API를 호출하려면cURL
을 사용합니다.curl -X PUT --data-binary @CORS_CONFIG_FILE \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "x-goog-project-id: PROJECT_ID" \ "https://storage.googleapis.com/BUCKET_NAME?cors"
각 항목의 의미는 다음과 같습니다.
BUCKET_NAME
은 버킷의 이름입니다. 예를 들면my-bucket
입니다.PROJECT_ID
는 버킷과 연결된 프로젝트의 ID입니다.my-project
).CORS_CONFIG_FILE
은 2단계에서 만든 XML 파일의 경로입니다.
버킷의 CORS 구성을 삭제하려면 빈 CORS 구성을 설정하세요.
버킷의 CORS 구성 보기
버킷의 CORS 구성을 보려면 다음 안내를 따르세요.
콘솔
Google Cloud 콘솔을 사용하여 CORS를 관리할 수 없습니다. 대신 gcloud CLI를 사용하세요.
명령줄
gcloud storage buckets describe
명령어를 --format
플래그와 함께 사용합니다.
gcloud storage buckets describe gs://BUCKET_NAME --format="default(cors_config)"
여기서 BUCKET_NAME
은 CORS 구성을 보려는 버킷의 이름입니다. 예를 들면 my-bucket
입니다.
클라이언트 라이브러리
클라이언트 라이브러리를 사용하여 버킷의 CORS 구성을 보려면 버킷 메타데이터 표시의 안내를 따라 응답에서 CORS 필드를 찾습니다.
C++
자세한 내용은 Cloud Storage C++ API 참조 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
C#
자세한 내용은 Cloud Storage C# API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Go
자세한 내용은 Cloud Storage Go API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Java
자세한 내용은 Cloud Storage Java API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Node.js
자세한 내용은 Cloud Storage Node.js API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
PHP
자세한 내용은 Cloud Storage PHP API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Python
자세한 내용은 Cloud Storage Python API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
Ruby
자세한 내용은 Cloud Storage Ruby API 참고 문서를 확인하세요.
Cloud Storage에 인증하려면 애플리케이션 기본 사용자 인증 정보를 설정합니다. 자세한 내용은 로컬 개발 환경의 인증 설정을 참조하세요.
REST API
JSON API
Authorization
헤더에 대한 액세스 토큰을 생성하려면 gcloud CLI가 설치 및 초기화되어 있어야 합니다.또는 OAuth 2.0 Playground를 사용하여 액세스 토큰을 만들고
Authorization
헤더에 포함할 수 있습니다.cURL
을 사용하여GET
버킷 요청으로 JSON API를 호출합니다.curl -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME?fields=cors"
여기서
BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.
XML API
Authorization
헤더에 대한 액세스 토큰을 생성하려면 gcloud CLI가 설치 및 초기화되어 있어야 합니다.또는 OAuth 2.0 Playground를 사용하여 액세스 토큰을 만들고
Authorization
헤더에 포함할 수 있습니다.cURL
을 사용하여?cors
로 범위가 지정된GET
버킷 요청으로 XML API를 호출합니다.curl -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://storage.googleapis.com/BUCKET_NAME?cors"
여기서
BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.
CORS 요청 문제 해결
다른 출처에서 Cloud Storage 버킷에 액세스할 때 예상치 못한 동작이 발생할 경우 다음 단계를 시도하세요.
대상 버킷에서 CORS 구성을 검토합니다. CORS 구성 항목이 여러 개 있으면 문제 해결에 사용하는 요청 값이 단일 CORS 구성 항목의 값에 매핑되어야 합니다.
CORS 요청을 허용하지 않는
storage.cloud.google.com
엔드포인트 요청을 수행하지 않는지 확인합니다. CORS가 지원되는 엔드포인트에 대한 자세한 내용은 Cloud Storage CORS 지원을 참조하세요.원하는 도구를 사용하여 요청 및 응답을 검토합니다. Chrome 브라우저에서는 표준 개발자 도구를 사용하여 이 정보를 볼 수 있습니다.
- 브라우저 툴바에서 Chrome 메뉴(more_vert)를 클릭합니다.
- 추가 도구 > 개발자 도구를 선택합니다.
- 네트워크 탭을 클릭합니다.
- 애플리케이션이나 명령줄에서 요청을 보냅니다.
- 네트워크 활동을 표시하는 창에서 요청을 찾습니다.
- 이름 열에서 요청에 해당하는 이름을 클릭합니다.
- 응답 헤더를 보려면 헤더 탭을 클릭하고, 응답 내용을 보려면 응답 탭을 클릭합니다.
응답 및 요청이 보이지 않으면 이전에 실패한 실행 전 요청 시도를 브라우저가 캐시한 것일 수도 있습니다. 브라우저의 캐시를 지우면 실행 전 캐시도 지워집니다. 그렇지 않은 경우 CORS 구성의
MaxAgeSec
값을 더 낮은 값으로 설정하고(값을 지정하지 않으면 기본값은 1,800(30분)), 이전의MaxAgeSec
이 얼마나 길었는지 관계없이 요청을 다시 시도합니다. 그러면 새로운 CORS 구성을 가져오고 캐시 항목을 삭제하는 새로운 실행 전 요청이 수행됩니다. 문제를 디버깅한 후에MaxAgeSec
을 다시 더 높은 값으로 올려서 버킷에 대한 실행 전 트래픽을 줄입니다.요청에
Origin
헤더가 있고, 이 헤더 값이 버킷의 CORS 구성에서 최소한 하나의Origins
값과 일치하는지 확인합니다. 스키마, 호스트, 포트의 값이 정확히 일치해야 합니다. 허용되는 일치의 몇 가지 예시는 다음과 같습니다.http://origin.example.com
은http://origin.example.com:80
과 일치하지만(80이 기본 HTTP 포트이기 때문)https://origin.example.com
,http://origin.example.com:8080
,http://origin.example.com:5151
또는http://sub.origin.example.com
과는 일치하지 않습니다.https://example.com:443
은https://example.com
과 일치하지만http://example.com
또는http://example.com:443
과는 일치하지 않습니다.http://localhost:8080
은http://localhost:5555
또는http://localhost.example.com:8080
가 아니라 정확히http://localhost:8080
과 일치합니다.
요청의 HTTP 메서드(단순 요청인 경우) 또는
Access-Control-Request-Method
에 지정된 메서드(실행 전 요청인 경우)가 버킷의 CORS 구성에서 최소한 하나의Methods
값과 일치하는지 확인합니다.실행 전 요청인 경우 하나 이상의
Access-Control-Request-Header
헤더를 포함하는지 확인합니다. 그렇다면 각Access-Control-Request-Header
값이 버킷의 CORS 구성에 있는ResponseHeader
값과 일치하는지 확인합니다. 실행 전 요청이 성공하고 응답에 CORS 헤더를 포함하려면Access-Control-Request-Header
에 명명된 모든 헤더가 CORS 구성에 있어야 합니다.
다음 단계
- 버킷에서 CORS 구성을 삭제하는 예시를 포함하여 CORS 구성 예시 살펴보기
- CORS 자세히 알아보기