97

In both image and script tags.

My understanding was that you can access both scripts and images on other domains. So when does one use this attribute?

Is this when you want to restrict the ability of others to access your scripts and image?

Images:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin

Scripts:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

simhumileco
  • 31,877
  • 16
  • 137
  • 115
Smurfette
  • 1,935
  • 2
  • 14
  • 15

6 Answers6

60

The answer can be found in the specification.

For img:

The crossorigin attribute is a CORS settings attribute. Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas.

and for script:

The crossorigin attribute is a CORS settings attribute. It controls, for scripts that are obtained from other origins, whether error information will be exposed.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 9
    They seem to have little in common, despite having the same name. One regards error control, the other is for use with canvas. – Smurfette Aug 20 '13 at 13:55
  • @Smurfette: The thing they have in common is that they modify how the element works when used from a cross-origin origin. But yes, they are indeed quite different otherwise. – T.J. Crowder Aug 20 '13 at 14:00
  • 1
    @Smurfette: This doesn't relate to them *blocking* you from using the images, just preventing (or allowing) your using them in `canvas` elements. – T.J. Crowder Aug 22 '13 at 17:31
  • Just an FYI that this attribute is also useful in link elements - when linking to an external stylesheet in Firefox (e.g. using Google fonts) this fixes issues that can arise if you have any scripts that access document.styleSheets – kinakuta Jan 27 '14 at 22:16
  • @Smurfette: Is there any such attribute for iFrame so that I can control the src from server side, if the request is coming from known Origin or not? – Akash Patra Aug 21 '14 at 06:30
  • Would you please explain `Its purpose is to allow images from third-party sites that allow cross-origin access to be used with canvas` in details? – Peyman Mohamadpour Nov 08 '16 at 08:13
38

This is how we have successfully used crossorigin attribute it in a script tag:

Problem we had: We were trying to log js errors in the server using window.onerror

Almost all of the errors that we were logging had this message : Script error. and we were getting very little information about how to solve these js errors.

It turns out that the native implementation in chrome to report errors

if (securityOrigin()->canRequest(targetUrl)) {
        message = errorMessage;
        line = lineNumber;
        sourceName = sourceURL;
} else {
        message = "Script error.";
        sourceName = String();
        line = 0;
}

will send message as Script error. if the requested static asset violates the browser's same-origin policy.

In our case we were serving the static asset from a cdn.

The way we solved it was adding the crossorigin attribute to the script tag.

P.S. Got all the info from this answer

Community
  • 1
  • 1
Omar Rayward
  • 481
  • 5
  • 8
33

CORS-enabled images can be reused in the element without being tainted. The allowed values are:

The page already answers your question.

If you have a cross-origin image you can copy it into a canvas but this "taints" the canvas which prevents you from reading it (so you cannot "steal" images e.g. from an intranet where the site itself doesn't have access to). However, by using CORS the server where the image is stored can tell the browser that cross-origin access is permitted and thus you can access the image data through a canvas.

MDN also has a page about just this thing: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

Is this when you want to restrict the ability of others to access your scripts and image?

No.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
4

If you're developing a quick piece of code locally, and you're using Chrome, there's a problem. if your page loads using a URL of the form "file://xxxx", then trying to use getImageData() on the canvas will fail, and throw the cross-origin security error, even if your image is being fetched from the same directory on your local machine as the HTML page rendering the canvas. So if your HTML page is fetched from, say:

file://D:/wwwroot/mydir/mytestpage.html

and your Javascript file and images are being fetched from, say:

file://D:/wwwroot/mydir/mycode.js

file://D:/wwwroot/mydir/myImage.png

then despite the fact that these secondary entities are being fetched from the same origin, the security error is still thrown.

For some reason, instead of setting the origin properly, Chrome sets the origin attribute of the requisite entities to "null", rendering it impossible to test code involving getImageData() simply by opening the HTML page in your browser and debugging locally.

Also, setting the crossOrigin property of the image to "anonymous" doesn't work, for the same reason.

I'm still trying to find a workaround for this, but once again, it seems that local debugging is being rendered as painful as possible by browser implementors.

I just tried running my code in Firefox, and Firefox gets it right, by recognising that my image is from the same origin as the HTML and JS scripts. So I'd welcome some hints on how to get round the problem in Chrome, as at the moment, while Firefox works, it's debugger is painfully slow, to the point of being one step removed from a denial of service attack.

David Edwards
  • 794
  • 8
  • 13
  • 1
    Thanks, this answer made me realize the issue I had might only affect local test environment, and it was. – WSBT Jul 27 '18 at 19:23
1

I've found out how to persuade Google Chrome to allow file:// references without throwing a cross-origin error.

Step 1: Create a shortcut (Windows) or the equivalent in other operating systems;

Step 2: Set the target to something like the following:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files

That special command line argument, --allow-file-access-from-files, tells Chrome to let you use file:// references to web pages, images etc., without throwing cross-origin errors every time you try to transfer those images to an HTML canvas, for example. It works on my Windows 7 setup, but it's worth checking to see if it will work on Windows 8/10 and various Linux distros too. If it does, problem solved - offline development resumes as normal.

Now I can reference images and JSON data from file:// URIs, without Chrome throwing cross-origin errors if I attempt to transfer image data to a canvas, or transfer JSON data to a form element.

David Edwards
  • 794
  • 8
  • 13
1

  1. By default, scripts are not subject to the same-origin policy and it can load third-party JavaScript from any cross-origin domain.

  2. Such rules have obvious security risk, such as:

  • Third-party JavaScript can access the error context of first-party websites, thereby obtaining internal information.
  • The third-party JavaScript source server can obtain user information through SSL handshake verification during requests, cookies and other means.
  1. To mitigate these security risks, browsers have introduced the crossorigin attribute for script tags.
  • Without the crossorigin attribute, it is impossible to obtain the error context of JavaScript.
  • Setting crossorigin to "anonymous" allows access to the error context of JavaScript but does not carry cookies or user credentials in SSL handshakes during requests.
  • Setting crossorigin to "use-credentials" allows access to both the error context of JavaScript and carries cookies or user credentials in SSL handshakes during requests.

Besides, around 2023, The HTTP cache of Chrome browser will also be affected by crossorigin attribute, see Cache control header not working for detail.

Junior Tour
  • 439
  • 7
  • 8