Gateway supports Cross-Origin Resource Sharing (CORS) so a specific bucket can be accessed by a web page in different domains. Configure a bucket to allow cross-origin resource access by using CORS configuration rules. These are two common scenarios for using CORS:

Outbound Access - Hosting a website in a bucket, but the site pages to use style sheets, images, and scripts are managed elsewhere. Because browsers block such requests from within scripts, configure the bucket to explicitly enable cross-origin requests.
Inbound Access - Hosting a public resource from a bucket. Because browsers require a CORS check (known as a preflight check), configure the bucket to allow any origin to make these requests.

See the W3C specification for CORS.

Note

Set CORS configuration using S3, not SCSP. A browser accessing the bucket receives the same CORS information in the response from both S3 and SCSP.

Enabling CORS on a Bucket

To configure a bucket to allow cross-origin requests, create a CORS configuration, an XML document with up to 100 rules identifying the origins that can access a bucket, the operations (HTTP methods) to support for each origin, and other operation-specific information. Add the XML document as the cors subresource to the bucket.

This cors configuration on a bucket has three rules (the CORSRule elements), which do the following:

Allow cross-origin PUT, POST, and DELETE requests from the https://www.example1.com origin and allow all headers in a preflight OPTIONS request through the Access-Control-Request-Headers header. In response to any preflight OPTIONS request, Gateway returns any requested headers.
Allow the same cross-origin requests as the first rule but to another origin, https://www.example2.com.
Allow cross-origin GET requests from all origins. The '*' wildcard character refers to all origins.

<CORSConfiguration>
   <CORSRule>
      <AllowedOrigin>http://www.example1.com</AllowedOrigin>
      <AllowedMethod>PUT</AllowedMethod>
      <AllowedMethod>POST</AllowedMethod>
      <AllowedMethod>DELETE</AllowedMethod>
      <AllowedHeader>*</AllowedHeader>
   </CORSRule>
   <CORSRule>
      <AllowedOrigin>http://www.example2.com</AllowedOrigin>
      <AllowedMethod>PUT</AllowedMethod>
      <AllowedMethod>POST</AllowedMethod>
      <AllowedMethod>DELETE</AllowedMethod>
      <AllowedHeader>*</AllowedHeader>
   </CORSRule>
   <CORSRule>
      <AllowedOrigin>*</AllowedOrigin>
      <AllowedMethod>GET</AllowedMethod>
   </CORSRule>
</CORSConfiguration>

The CORS configuration allows optional configuration parameters, as shown in this CORS configuration that allows cross-origin PUT and POST requests from http://www.example.com:

<CORSConfiguration>
   <CORSRule>
      <AllowedOrigin>http://www.example.com</AllowedOrigin>
      <AllowedMethod>PUT</AllowedMethod>
      <AllowedMethod>POST</AllowedMethod>
      <AllowedMethod>DELETE</AllowedMethod>
      <AllowedHeader>*</AllowedHeader>
      <MaxAgeSeconds>3000</MaxAgeSeconds>
      <ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
      <ExposeHeader>x-amz-request-id</ExposeHeader>
      <ExposeHeader>x-amz-id-2</ExposeHeader>
   </CORSRule>
</CORSConfiguration>

CORSRule Elements

Element	Description

Element	Description
AllowedMethod	Specifies which of the following values is allowed: GET, PUT, POST, DELETE, HEAD
AllowedOrigin	Specifies the origins cross-domain requests are allowed from: `http://www.example.com`/. The origin string can contain at most one * wildcard character, such as `http://.example.com`. Optionally specify as the origin to enable all origins to send cross-origin requests. Specify `https` to enable only secure origins.
AllowedHeader	Specifies which headers are allowed in a preflight request through the Access-Control-Request-Headers header. Each header name in the Access-Control-Request-Headers header must match a corresponding entry in the rule. Gateway sends only the allowed headers in a response requested. Each AllowedHeader string in the rule can contain at most one * wildcard character. `<AllowedHeader>x-amz-*</AllowedHeader>` enables all Amazon-specific headers.
ExposeHeader	Identifies a header in the response clients are able to access from applications (Example: From a JavaScript XMLHttpRequest object).
MaxAgeSeconds	Specifies the time in seconds a browser can cache the response for a preflight request as identified by the resource, the HTTP method, and the origin. By caching the response, the browser does not need to send preflight requests if the original request is to be repeated.

Swarm Documentation

Gateway CORS for Buckets

Note

Enabling CORS on a Bucket

CORSRule Elements