Monday, November 10th, 2008
Thanks to Chris Double I saw the email thread on cross origin access to media files via the video and audio HTML 5 tags.
Jonas Sicking does a great job at explaining the issue, and why we need to restrict access. This is going to take a lot of people by surprised. Most will assume that you can
video src="my cdn" to another domain just as you can with img, iframe, and a few others. Having to tweak server side headers is a significant barrier (remember why PHP did so well?) and as we move to the cloud, it is yet another feature that is required, so we can let users tweak it.
But, let’s listen in to Jonas and his thoughts on why, despite the pain, we need to do this correctly:
It is an absolute requirement from a security point of view that data is
not leaked cross site. We don’t want a page on an internet server, lets
call it attacker.com, to read data that lives on an intranet server
behind a firewall, intranet.com.
It is also important that that one site, attacker.com, can’t read
personal data stored on other site, bank.com. If it could it would be
possible for any site to read your bank statements as soon as you log in
to your bank.
This is why we for example only allow XMLHttpRequest to make requests to
the same site, but not other sites.
Unfortunately we have inherited a few exceptions to this same-site rule
from the olden, more innocent, days of the internet when security wasn’t
as heavily considered. This is why for example <img>, <iframe>, <link
rel=stylesheet>, and <script> can be used cross site.
In all of these cases we try very hard to limit access as much as possible.
For example while you can display another site in an <iframe>, you can’t
reach in to the DOM of the page. However click-jacking was recently
discovered which might mean that we’ll have to put very complex
restrictions on iframes. Or rely on that sites deploy their own
protections against it. Many probably won’t due to not knowing about the
And while you can style your page using a cross site <link
rel=stylesheet> you can’t read parse errors since then you could point
to a url of a HTML page that contains sensitive data and potentially get
sensitive information through the parse error messages. We are somewhat
saved here by the fact that it seems very unlikely that someone would
put sensitive data into a stylesheet.
However if someone did, for example a stylesheet setting a background
color to different colors depending on portfolio results in the last
quarter, that data could be read by any site on the internet. Even if
the stylesheet lives on a server protected by firewalls and/or requires
login. This is something that web developers simply has to know. Most
We are in a bad situation with <script> and we have had situations where
sensitive JSON data could be read by pointing a <script> tag at it. The
With <img> we are trying very hard to not expose more than what we can’t
prevent. So for example you can get the size of the image (since we
can’t prevent that anyway since it affects layout), but you can’t get
the pixel data. If we allowed pixel data to be retrieved, again any site
on the internet could read any image data placed on a webserver, even if
protected by passwords/firewalls.
This has prevented the API for <img> to remain unchained for years. And
when we added <canvas> we had to deal with tainting which can cause
confusing behaviors for developers since suddenly certain APIs break. As
roc recently pointed out, pointer-events is another recent expansion of
the browser API which is going to get much harder to implement due to
the unchecked cross-site loading of <img>, and for sure result in that
cross-site images will work differently from same-site images.
Posted by Dion Almaer at 7:07 am