CORS Configuration
When delivering content from your servinga S3 Object Storage bucket right to the browser, CORS (Cross-Origin Resource Sharing) is usually a concern for most modern browsers. In order to avoid CORS-related issues, you can submit a CORS configuration to your bucket to control which CORS headers are being sent back to your visitor's browser.
Configuration
As with e.g. the lifecycle policy of a bucket, the CORS configuration is being defined in a XML document. You can define one CORS configuration per bucket, however a single CORS configuration document can consist of multiple CORS rules.
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedOrigin>https://*.example.com</AllowedOrigin>
<AllowedOrigin>https://*.another-example.com</AllowedOrigin>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
<CORSRule>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<AllowedOrigin>*</AllowedOrigin>
</CORSRule>
</CORSConfiguration>
The example configuration above allows PUT, DELETE, POST, GET and HEAD requests from the https://*.example.com and https://*.another-example.com domains to your bucket. It also allows GET and HEAD requests from any domain.
This might be a classic example of a CORS configuration where you have a frontend application that is being used to upload files to or delete files from your bucket whereas the content might need to be served to the browser from other domains.
You can apply a CORS configuration to your bucket by submitting the XML document to the PUT Bucket CORS API endpoint, e.g. by using s3cmd which offers a command line interface sub-command to do so:
s3cmd setcors cors-configuration.xml s3://your-bucket
In order to cross-check whether the CORS configuration has been correctly applied to your bucket, you can use the getcors sub-command:
s3cmd getcors s3://your-bucket