How to setup Cross-Origin Resource Sharing (CORS) on DreamObjects

This article describes how to set up the Cross-Origin Resource Sharing (CORS) capabilities of DreamObjects as implemented in Ceph, and is intended for any users that need to set up DreamObjects for use across domains, such as WebFonts, or cross-domain uploads.

Background and use cases

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g., fonts) on a web page to become available to another domain outside the domain from which the resource originated. A restricted resource is any that would violate the same-origin policy of the browser.

In plain terms, a CORS policy request is how the browser determines if it’s actually permitted to perform non-trivial requests from one domain to another. Some canonical examples of these are WebFonts and JavaScript-based (XMLHttpRequest) uploads to an external storage service.

Use case: Cross-domain uploads

Historically, if a site had file upload functionality, the upload (via a form) could occur to any site. The browser did not consider any security implications of the POST to another site. JavaScript code however was subject to the same-origin policy, and not permitted to contact another domain. Fancy upload forms using JavaScript and XMLHttpRequest were greatly limited by the same-origin policy, especially as cloud storage services increased in popularity. A CORS policy for uploading files using XMLHttpRequest must specify that the browser is permitted to POST/PUT a file if it’s coming from a given website.

Use case: WebFont usage

WebFonts use the same-origin policy as part of an answer to the DRM needs to prevent fonts from being used outside of their licensing terms. Leaving aside any discussion of the effectiveness of this policy, web fonts must be able to work on web sites with specific graphic design needs. The CORS policy for a WebFont must specify that it’s permitted to download (GET request) the WebFont for use on a given website.

Deploying a CORS configuration

A minority of S3 clients support deploying CORS configurations. Some (such as boto) also support programmatically constructing a CORS configuration. (See the links in the clients section below for examples of deploying a CORS configuration on various clients.) Other clients not listed may also support CORS policies, and the listing should not be taken as exhaustive or guaranteed correct (some clients have experienced broken CORS support at some points).

s3cmd (1.6.0 and newer)

Since 1.6.0, S3cmd supports setting or deleting a CORS config; however it does not support getting it back except as a part of an “info” request.