교차 출처 리소스 공유(CORS)는 출처가 서로 다른 리소스 간의 상호작용을 허용합니다. 일반적으로 이러한 상호작용은 악의적인 행동을 방지하기 위해 금지되어 있습니다. 이 주제를 통해 Cloud Storage 버킷에서 CORS를 구성하는 방법에 대해 알아보세요.
버킷에서 CORS 구성
버킷이 수락할 수 있는 요청 유형을 식별하는 HTTP 메서드 및 출처 도메인과 같은 정보를 지정하여 버킷에 CORS 구성을 설정합니다.
버킷에 CORS 구성을 설정하려면 다음 단계를 따르세요.
콘솔
Google Cloud Console을 사용하여 CORS를 관리할 수 없습니다. 대신 gsutil을 사용하세요.
gsutil
적용하려는 CORS 구성을 사용해서 JSON 파일을 만듭니다. 샘플 JSON 파일은 구성 예시를 참조하세요.
gsutil cors
명령어를 사용하여 버킷에 구성을 적용합니다.gsutil cors set CORS_CONFIG_FILE gs://BUCKET_NAME
각 항목의 의미는 다음과 같습니다.
CORS_CONFIG_FILE
은 1단계에서 만든 JSON 파일의 경로입니다.BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.
코드 샘플
C++
자세한 내용은 Cloud Storage C++ API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
C#
자세한 내용은 Cloud Storage C# API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
Go
자세한 내용은 Cloud Storage Go API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
자바
자세한 내용은 Cloud Storage 자바 API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
Node.js
자세한 내용은 Cloud Storage Node.js API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
PHP
자세한 내용은 Cloud Storage PHP API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
Python
자세한 내용은 Cloud Storage Python API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
Ruby
자세한 내용은 Cloud Storage Ruby API 참조 문서를 확인하세요.
다음 샘플에서는 버킷에 CORS 구성을 설정합니다.
다음 샘플에서는 버킷에서 모든 기존 CORS 구성을 삭제합니다.
REST API
JSON API
- OAuth 2.0 Playground에서 승인 액세스 토큰을 가져옵니다. 자체 OAuth 사용자 인증 정보를 사용하도록 Playground를 구성합니다. 자세한 내용은 API 인증을 참조하세요.
적용하려는 CORS 구성을 사용해서 JSON 파일을 만듭니다. 샘플 JSON 파일은 구성 예시를 참조하세요.
cURL
을 사용하여PATCH
버킷 요청으로 JSON API를 호출합니다.curl --request PATCH \ 'https://storage.googleapis.com/storage/v1/b/BUCKET_NAME?fields=cors' \ --header 'Authorization: Bearer OAUTH2_TOKEN' \ --header 'Content-Type: application/json' \ --data-binary @CORS_CONFIG_FILE
각 항목의 의미는 다음과 같습니다.
BUCKET_NAME
은 버킷의 이름입니다. 예를 들면my-bucket
입니다.OAUTH2_TOKEN
은 1단계에서 생성한 액세스 토큰입니다.CORS_CONFIG_FILE
은 2단계에서 만든 JSON 파일의 경로입니다.
XML API
- OAuth 2.0 Playground에서 승인 액세스 토큰을 가져옵니다. 자체 OAuth 사용자 인증 정보를 사용하도록 Playground를 구성합니다. 자세한 내용은 API 인증을 참조하세요.
cURL
을 사용하여Set Bucket CORS
요청으로 XML API를 호출합니다.curl -X PUT --data-binary @CORS_CONFIG_FILE \ -H "Authorization: Bearer OAUTH2_TOKEN" \ -H "x-goog-project-id: PROJECT_ID" \ "https://storage.googleapis.com/BUCKET_NAME?cors"
각 항목의 의미는 다음과 같습니다.
BUCKET_NAME
은 버킷의 이름입니다. 예를 들면my-bucket
입니다.OAUTH2_TOKEN
은 1단계에서 생성한 액세스 토큰입니다.PROJECT_ID
는 버킷과 연결된 프로젝트의 ID입니다.my-project
).CORS_CONFIG_FILE
은 2단계에서 만든 XML 파일의 경로입니다.
버킷의 CORS 구성 보기
버킷의 CORS 구성을 보려면 다음 안내를 따르세요.
콘솔
Google Cloud Console을 사용하여 CORS를 관리할 수 없습니다. 대신 gsutil을 사용하세요.
gsutil
gsutil cors
명령어를 사용하여 버킷의 CORS 구성을 가져옵니다.
gsutil cors get gs://BUCKET_NAME
여기서 BUCKET_NAME
은 버킷의 이름입니다. 예를 들면 my-bucket
입니다.
코드 샘플
클라이언트 라이브러리를 사용하여 버킷의 CORS 구성을 보려면 버킷 메타데이터 표시의 안내를 따라 응답에서 CORS 필드를 찾습니다.
C++
자세한 내용은 Cloud Storage C++ API 참조 문서를 확인하세요.
C#
자세한 내용은 Cloud Storage C# API 참조 문서를 확인하세요.
Go
자세한 내용은 Cloud Storage Go API 참조 문서를 확인하세요.
자바
자세한 내용은 Cloud Storage 자바 API 참조 문서를 확인하세요.
Node.js
자세한 내용은 Cloud Storage Node.js API 참조 문서를 확인하세요.
PHP
자세한 내용은 Cloud Storage PHP API 참조 문서를 확인하세요.
Python
자세한 내용은 Cloud Storage Python API 참조 문서를 확인하세요.
Ruby
자세한 내용은 Cloud Storage Ruby API 참조 문서를 확인하세요.
REST API
JSON API
- OAuth 2.0 Playground에서 승인 액세스 토큰을 가져옵니다. 자체 OAuth 사용자 인증 정보를 사용하도록 Playground를 구성합니다. 자세한 내용은 API 인증을 참조하세요.
cURL
을 사용하여GET
버킷 요청으로 JSON API를 호출합니다.curl -X GET \ -H "Authorization: Bearer OAUTH2_TOKEN" \ "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME?fields=cors"
각 항목의 의미는 다음과 같습니다.
OAUTH2_TOKEN
은 1단계에서 생성한 액세스 토큰의 이름입니다.BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.
XML API
- OAuth 2.0 Playground에서 승인 액세스 토큰을 가져옵니다. 자체 OAuth 사용자 인증 정보를 사용하도록 Playground를 구성합니다. 자세한 내용은 API 인증을 참조하세요.
cURL
을 사용하여GET
버킷 요청으로 XML API를 호출합니다.curl -X GET \ -H "Authorization: Bearer OAUTH2_TOKEN" \ "https://storage.googleapis.com/BUCKET_NAME?cors"
각 항목의 의미는 다음과 같습니다.
OAUTH2_TOKEN
은 1단계에서 생성한 액세스 토큰의 이름입니다.BUCKET_NAME
은 관련 버킷의 이름입니다. 예를 들면my-bucket
입니다.
CORS 요청 문제 해결
다른 출처에서 Cloud Storage 버킷에 액세스할 때 예상치 못한 동작이 발생할 경우 다음 단계를 시도하세요.
대상 버킷에서 CORS 구성을 검토합니다. CORS 구성 항목이 여러 개 있으면 문제 해결에 사용하는 요청 값이 단일 CORS 구성 항목의 값에 매핑되어야 합니다.
CORS 요청을 허용하지 않는
storage.cloud.google.com
엔드포인트 요청을 수행하지 않는지 확인합니다. CORS가 지원되는 엔드포인트에 대한 자세한 내용은 Cloud Storage CORS 지원을 참조하세요.원하는 도구를 사용하여 요청 및 응답을 검토합니다. Chrome 브라우저에서는 표준 개발자 도구를 사용하여 이 정보를 볼 수 있습니다.
- 브라우저 툴바에서 Chrome 메뉴
을 클릭합니다.
- 추가 도구 > 개발자 도구를 선택합니다.
- 네트워크 탭을 클릭합니다.
- 애플리케이션이나 명령줄에서 요청을 보냅니다.
- 네트워크 활동을 표시하는 창에서 요청을 찾습니다.
- 이름 열에서 요청에 해당하는 이름을 클릭합니다.
- 응답 헤더를 보려면 헤더 탭을 클릭하고, 응답 내용을 보려면 응답 탭을 클릭합니다.
응답 및 요청이 보이지 않으면 이전에 실패한 실행 전 요청 시도를 브라우저가 캐시한 것일 수도 있습니다. 브라우저의 캐시를 지우면 실행 전 캐시도 지워집니다. 그렇지 않은 경우 CORS 구성의
MaxAgeSec
값을 더 낮은 값으로 설정하고(값을 지정하지 않으면 기본값은 1,800(30분)), 이전의MaxAgeSec
이 얼마나 길었는지 관계없이 요청을 다시 시도합니다. 그러면 새로운 CORS 구성을 가져오고 캐시 항목을 삭제하는 새로운 실행 전 요청이 수행됩니다. 문제를 디버깅한 후에MaxAgeSec
을 다시 더 높은 값으로 올려서 버킷에 대한 실행 전 트래픽을 줄입니다.- 브라우저 툴바에서 Chrome 메뉴
요청에
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 구성
App Engine에서 실행 중인 동적 웹사이트가 있고 사용자가 your-example-website.appspot.com
에서 액세스할 수 있다고 가정해 보겠습니다. 글꼴 파일이 your-example-bucket
이라는 Cloud Storage 버킷에 호스팅되어 있습니다. 웹사이트에서 글꼴을 사용하려는 경우, your-example-bucket
에 CORS 구성을 적용하여 사용자의 브라우저가 버킷에서 리소스를 요청할 수 있도록 해야 합니다. 아래 구성에 따라 실행 전 요청은 1시간 동안 유효하고, 브라우저 요청이 성공하면 응답에 리소스의 Content-Type
이 반환됩니다.
gsutil
[ { "origin": ["https://your-example-website.appspot.com"], "method": ["GET"], "responseHeader": ["Content-Type"], "maxAgeSeconds": 3600 } ]
쉼표로 구분된 목록을 사용하여 여러 출처, 메서드 또는 헤더를 지정할 수 있습니다. 예를 들면 "method": ["GET", "PUT"]
입니다.
CORS 구성을 설정하는 방법에 대한 자세한 내용은 gsutil cors
문서를 참조하세요.
REST API
JSON API
{ "cors": [ { "origin": ["https://your-example-website.appspot.com"], "method": ["GET"], "responseHeader": ["Content-Type"], "maxAgeSeconds": 3600 } ] }
쉼표로 구분된 목록을 사용하여 여러 출처, 메서드 또는 헤더를 지정할 수 있습니다. 예를 들면 "method": ["GET", "PUT"]
입니다.
일반적인 형식의 CORS 구성 파일은 JSON의 버킷 리소스 표현을 참조하세요.
XML API
<?xml version="1.0" encoding="UTF-8"?> <CorsConfig> <Cors> <Origins> <Origin>https://your-example-website.appspot.com</Origin> </Origins> <Methods> <Method>GET</Method> </Methods> <ResponseHeaders> <ResponseHeader>Content-Type</ResponseHeader> </ResponseHeaders> <MaxAgeSec>3600</MaxAgeSec> </Cors> </CorsConfig>
여러 개의 출처, 메서드, 헤더를 각각에 대한 개별 요소를 사용하여 지정할 수 있습니다. 예를 들어 <Methods>
요소 내에는 <Method>GET</Method>
및 <Method>PUT</Method>
이 있습니다.
일반적인 형식의 CORS 구성 파일은 XML용 CORS 구성 형식을 참조하세요.
CORS 구성 삭제
버킷에 설정된 경우 다음 구성은 버킷의 모든 현재 CORS 설정을 삭제합니다.
gsutil
[]
CORS 구성을 설정하는 방법에 대한 자세한 내용은 gsutil cors
문서를 참조하세요.
REST API
JSON API
{ "cors": [] }
일반적인 형식의 CORS 구성 파일은 JSON의 버킷 리소스 표현을 참조하세요.
XML API
<CorsConfig></CorsConfig>
일반적인 형식의 CORS 구성 파일은 XML용 CORS 구성 형식을 참조하세요.
다음 단계
- 교차 출처 리소스 공유(CORS)에 대해 자세히 알아보기