Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users
Status: Fixed
User never visited
Closed: Jun 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
CORS for canvas (drawImage and texImage2D)
Reported by, May 9 2011 Back to list
Cross-Origin Resource Sharing should allow drawing cross-domain image/video elements into canvas 2D and WebGL contexts without tainting the origin-clean state of the canvas (so toDataURL/getImageData/readPixels still work).
Comment 1 by, Jun 24 2011
I'm seeing this with: 13.0.782.32 (Official Build 89955) beta

Sending this HTTP header when returning the image resource from the other domain does not help:
  Access-Control-Allow-Origin: *

I still get a:
  Uncaught Error: SECURITY_ERR: DOM Exception 18

Comment 2 by, Jun 24 2011
Labels: -Area-Undefined Area-WebKit Mstone-13
Status: Fixed
This was implemented by abarth and japhet, culminating in and is in Chrome M13.

@fredsa, I'll update the other bug with more information -- your test case appears to be passing now.

Comment 3 by, Jul 7 2011
I'm on Chrome 14 (14.0.803.0 dev) and still get "Error: SECURITY_ERR: DOM Exception 18" when trying toDataURL on canvas that has cross-origin image (but with "access-control-allow-origin: *") drawn.
Comment 4 by, Jul 7 2011
Please provide a test case. This functionality is known to be working, though there are bugs -- for example, if the image was cached without the CORS state, then you'll need to clear the cache to get it to be picked up. Also, it is necessary to set the crossOrigin attribute of the image element to "" or "anonymous" in order for any CORS headers in the response to be obeyed.

Comment 5 by, Jul 7 2011
I wasn't aware of "crossOrigin" property. Is this non-standard? How come mere presence of header doesn't leave origin-clean set to true?
The crossOrigin attribute is part of HTML5.

It's necessary because it changes how the request is sent (e.g., without cookies), which makes the whole thing secure.
Comment 7 by, Jul 7 2011
See for some more background and information on the newly introduced and implemented crossOrigin attribute.

Comment 8 by, Jul 7 2011
I searched current version of WHATWG, as well as CORS draft but don't see any mention of "crossOrigin" property. Could you point me to where it's spec'd?

I also don't see why it's necessary to set "crossOrigin" in order for canvas to not lose its "origin-clean" flag? Isn't the point of SOP restriction in `toDataURL` to prevent data leaking from remote resource? Why would it matter if image request was sent with cookies or not? If remote resource explicitly permits data to be read from other origins, why should those origins be setting property on images?
It's a design property of CORS that sending Access-Control-Allow-Origin: * doesn't expose cookie-protected content.  The working group made that decision based on implementation experience with Flash's crossdomain.xml file, which is a security disaster because it has an "allow *" that exposes cookie protected content.

In any case, this isn't the proper forum to discuss these issues.  The proper forum is the W3C.
Did something change with CORS handling for WebGL (texImage2D)? 

New Chrome Canary 17.0.919.0 started to throw CORS exceptions for images coming from the same origin when requested with image.crossOrigin = '';

Is this intended behavior or a bug?

WebGL specs are somehow unclear on this - what should happen when you ask for CORS resource with the same origin and server then doesn't grant permission. 

Comment 12 by, Oct 27 2011
This was a recent change in WebKit implemented by abarth to bring WebKit's CORS implementation into compliance. See .

If an anonymous CORS-enabled fetch is made and the server doesn't grant permission, the fetched data is dropped and an error is reported.

This has been Firefox's behavior; WebKit's previous behavior was incorrect.


At least on Windows 7, Firefox behaves differently. Both current stable Firefox 7.0.1 and latest Firefox nightly 10.0a1 (2011-10-27) do work ok with examples that throw CORS exception on latest Chrome Canary 17.0.919.0.

Just to clarify - the use case that started to behave differently recently is when you ask for anonymous CORS (by setting image.crossOrigin='') even when it would not be needed (because the script and image share the same origin).

Can you file a new bugs with this information in and cc me (with my email address).  I'll follow up and make sure we've got this correct.
Thanks for looking into this. I filed WebKit issue here:
I've uploaded a patch to the WebKit issue.
Project Member Comment 18 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 19 by, Mar 10 2013
Labels: -Area-WebKit -Mstone-13 Cr-Content M-13
Project Member Comment 20 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 21 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment