Cross-domain WebGL textures disabled in Firefox 5

In Firefox 5, it is no longer possible to use cross-domain elements as the source for WebGL textures. We made this change in response to security concerns around the possibility of cross domain information leakage. Unfortunately, that means that some WebGL-using pages are no longer working. We are working with the WebGL WG on a solution to allow such pages to resume working as soon as possible — read on for details.

The security rules about cross-domain images

A cross-domain image is an image coming from a different domain than the canvas. A basic rule of Web security is that scripts must not be able to read pixel data from cross-domain images — they can only “blindly” display them. In more concrete terms, imagine that you currently have a session open on your bank’s website, allowing you to download scanned copies of cheques you’ve written. You don’t want scripts loaded in other tabs, from other websites, to be able to read your scanned cheques! Similarly, when you draw a cross-domain image onto a 2D canvas, using drawImage(), the canvas becomes “tainted” so that it’s no longer possible for scripts to read its pixels. This prevents a loophole whereby a canvas would be used as a proxy to read cross-domain images.

The problem with cross-domain images as WebGL textures

When a cross-domain image was used as a WebGL texture, the WebGL canvas was “tainted” so that reading from it was no longer possible. Theoretically, that eliminated the concern. But a while ago, a researcher wrote to the public WebGL list with a possible attack that could still allow reading pixels from WebGL textures. The idea was to paint the texture one pixel at a time with a WebGL fragment shader crafted to take an amount of time proportional to its brightness, and then time how long it takes: that would conceivably allow to get an approximation of the original image. Initially this attack seemed difficult to execute practically, but since then further research, including a proof-of-concept has been published which shows the attack to be more realistic than initially expected.

The response

The WebGL spec has been updated to disallow using cross-domain images as WebGL textures, and Mozilla’s implementation in Firefox 5 has been updated accordingly. A non-normative section has also been added allowing cross-domain images that have CORS approval. Using CORS in this case is a way for servers to explicitly say when an image is OK to be read by cross-domain scripts. CORS support for WebGL is a high priority for us and will be implemented very soon.

A wiki page explains some more details. Affected scripts will generate a DOM_SECURITY_ERR exception and, just before that, a JS warning explaining what happened and linking to that wiki page.

Having to make this change is unfortunate, as it breaks some existing Web content. We initially wanted to wait for the CORS approach to be implemented before we blocked cross-domain textures. Our primary priority has always been the safety of our users, though, and so we decided to fix the security issue immediately in Firefox 5. This timing also accounts for the fact that CORS handling will become increasingly useful only as online content providers roll out support.


  1. phillihp

    I didn’t hear about this, fascinating. You could always simply pipe it through a small tunnel script.

    June 10th, 2011 at 12:19

  2. Gary Coding

    This broke loading a WebGL page with textures from a file: URL.
    I think it should treat texture files in the same dir or any child dir as being in the same domain. It does not.

    June 21st, 2011 at 23:21

    1. Benoit Jacob

      @ Gary:
      You can set security.fileuri.strict_origin_policy to true in about:config if you want file:// URIs to be considered as same-origin. This is not specific to WebGL textures. By default we enforce the strict origin policy for file:// URIs.

      June 22nd, 2011 at 04:34

      1. Julian Adams


        That contradicts this page:, which says that same directory or subdirectory counts as same origin (even whe strict_origin_policy is true). Should I file it as a bug?

        June 22nd, 2011 at 05:39

        1. Benoit Jacob

          @ Julian: I didn’t mean otherwise, sorry if that was unclear. Only file a bug if you see file:// uris being treated differently for WebGL textures than for other things for which same-origin restrictions apply.

          June 22nd, 2011 at 05:55

  3. Gry Coding

    @Benoit: Yes, file:// uris are being treated differently for WebGL textures than for other things for which same-origin restrictions apply.

    @Julian: Thanks for clarifying my post.

    An easy to setup test for this: grab this file and the two JS files and 1 GIF it uses and drop all in a local dir.

    June 22nd, 2011 at 09:27

  4. skierpage

    Please fix Flight of the Navigator, with Firefox 5 on Windows Vista it spews out lots of

    Warning: WebGL: The canvas used as source for texImage2D here is tainted (write-only). It is forbidden to load a WebGL texture from a tainted canvas. A Canvas becomes tainted for example when a cross-domain image is drawn on it. See
    Source File:
    Line: 446

    Error: uncaught exception: [Exception… “Failure arg 5 [nsIDOMWebGLRenderingContext.texImage2D]” nsresult: “0x80004005 (NS_ERROR_FAILURE)” location: “JS frame :: :: updateFlickrTexture :: line 446″ data: no]

    July 19th, 2011 at 14:55

    1. louisremi

      Cross-domain WebGL textures are now enabled in Firefox nightly with appropriate CORS headers.
      Fixing this demo would require to write a proxy that would fetch images from Flickr and add the appropriate header…

      July 20th, 2011 at 07:37

  5. Henri Astre

    In a very particular context I’ve found a workaround to be able to display texture from cross-domain without CORS headers:

    October 4th, 2011 at 09:34

Comments are closed for this article.