Purpose of the crossorigin attribute...?

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

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.

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

> 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.

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.

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.