The pains of Cross Origin Resource Sharing

HTML5 is booming and plugin based media distribution is diminishing. This however brings a number of new challenges like granting HTML5 players access to the actual media content. This can be complex as web browsers come with strict security restrictions on which content can and can't be loaded. One way to allow content to be accessed on other pages, is using Cross Origin Resource Sharing.

What is Cross Origin Resource Sharing (CORS)?

Making resources available across origins is one of the painful problems on the internet today. However, recent evolutions shouldn't make it so hard. A first question however, is why this is so difficult.

The reason of this, is the Same-Origin Policy, allowing browsers to only load resources which are originating from the same origin, roughly the same (sub)domain. The same-origin policy was called to life in order to prevent malicious websites from accessing content on other websites using the users credentials and log-in information. However, there are some kinds of resources you want to make available for other origins also, for example an API made available on a subdomain, or content located on a CDN. In order to do this, multiple techniques were developed like JSONP, a technique which is suited for API-calls when, for example, JSON data needs to be passed. An other popular technique is setting up a reverse proxy, hosted on the same origin, which can be used to make the data available without the need for contacting a different origin. While these methods provide workarounds, they are not a clean solution and either modify the content or require you to retransmit it.

The clean solution called CORS

As a solution for this, the Cross Origin Resource Sharing, or CORS, standard was contrived.

Cross Origin Resource Sharing allows to signal which information can be retrieved by different origins, and makes use of HTTP-headers. The method is actually similar to the crossdomain.xml-files which are used to signal cross domain access in the Flash plugin-environment and which lists which domains can access content. You might remember adding crossdomain.xml-files to your streaming servers, for example:

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*.theoplayer.com" />
</cross-domain-policy>

Most popular HTML5 platforms these days provide support for Cross Origin Resource Sharing, with support on all popular browsers on both desktop and mobile and modern devices such as Chromecast and smart TVs. The modern HTML5 players such as the THEOplayer HLS and DASH player and the dash.js reference player require CORS to be enabled on content when streaming from a different origin.

How does Cross Origin Resource Sharing work?

There are many different levels of CORS configurations. In it's most basic form, it suffices to return an Access-Control-Allow-Origin response header whenever an Origin request header is received. By setting the value of this header to the value of the Origin header, the browser will be signalled it is safe to use the content. For example, a browser might perform the following request:

GET /video/sintel/index.m3u8 HTTP/1.1
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Host:cdn.theoplayer.com
Origin:https://www.theoplayer.com
Pragma:no-cache
Referer:https://www.theoplayer.com/benchmark/index.html
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

In order to signal the browser it is allowed to use the response of this request, the server could return the following response headers:

HTTP/1.1 200 OK
Accept-Ranges:bytes
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:https://www.theoplayer.com
Access-Control-Max-Age:3000
Age:45446
Connection:keep-alive
Content-Length:978
Content-Type:application/octet-stream
Date:Tue, 13 Oct 2015 20:01:46 GMT
ETag:"4f7f9f0c441f40e238c31084bce4b19d"
Last-Modified:Thu, 30 Jul 2015 13:07:39 GMT
Server:AmazonS3
Vary:Origin,Access-Control-Request-Headers,Access-Control-Request-Method
Via:1.1 289241c3af05a479dc26e3b6a8f02210.cloudfront.net (CloudFront)
X-Amz-Cf-Id:aKbEBlFmcT74paZLGqhpKZXd3Unc5r31RiPzVm5N1oRyw590EHifJg==
X-Cache:Hit from cloudfront

In this response, note the Access-Control-Allow-* headers.

• "Access-Control-Allow-Methods:GET" shows GET-requests are allowed and can be used to allow other methods such as POST or PUT.
• "Access-Control-Allow-Origin:https://www.theoplayer.com" provides access to the https://www.theoplayer.com origin. Alternatively a wildcard "*" can be used to allow all origins.
• "Access-Control-Max-Age:3000" indicates the browser should re-check the CORS authorisation in 3000 seconds.

In the case the browser is performing other than a simple cross-origin request, the Cross Origin Resource Sharing specification specifies a preflight OPTIONS request in order to retrieve which actions the browser is allowed to perform. Using the preflight request, it is possible to allow other HTTP methods, expose custom headers and can allow credentials to be shared. The following response headers are also defined in the CORS specification and are usually sent in answer to a preflight request:

• "Access-Control-Allow-Credentials" can be used to allow credentials, such as cookies, to be sent with the CORS request.
• "Access-Control-Expose-Headers" indicates which response headers returned by the server can be exposed in the JavaScript API.
• "Access-Control-Allow-Headers" signals the browser which headers it can send to the server when sending the actual cross origin request.

Enabling basic CORS support can be as easy as adding a single header "Access-Control-Allow-Origin:*". Below this article, we have added a listing of how CORS can be enabled on popular media servers and CDNs. This list is a growing work in progress and will be updated over time when new information becomes available. A reference of how you can enable CORS on standard web servers, can be found on the enable-cors website.