I'm a bit confused regarding the subject of Same Origin Policy (SOP). If I understand correctly, the purpose of the SOP is to prevent one page from obtaining access to sensitive data on another web page.
So for example, how come I can simply get a sensitive image from a different origin? That would violate the idea of the SOP.
This is considered acceptable because scripts are limited in interacting with cross origin images unless crossorigin="anonymous" is set, which tells the browser not to send cookies or other credentials when retrieving the image. Without setting crossorigin="anonymous" scripts are allowed to retrieve dimensions, but not pixel data from the image due to the tainted canvas.
This is fine in theory, although there have been side channel attacks in the past that leak pixel data.
Access-Control-* header to block even images from being loaded by a foreign website?
Commented
Mar 13, 2021 at 1:39
The app cannot get any sensitive data from the IMG tag. If you try to read the pixel data with a <canvas> tag for example, the browser should throw a SOP exception, unless CORS is used. Since the image can be viewed (by the human user) but not programatically inspected (by JS code), the image policy is considered "good enough".
I should point out that it is possible to get the image dimensions from a remote image, which might be considered sensitive info, especially on dynamic image urls that show a "good/bad" image of different dimensions that alters based on some status. Still, that a very minimal amount of info, and not typically a privacy concern - also, it is hard to hide because image dimensions can usually be derived by how they affect the page layout (which is accessible to scripts).
To change this policy would break a ton of sites, which require "deep linking" to show assets from content delivery networks, imgur, etc.
The Same Origin Policy isn't some uniform clean axiom: it's actually a set of specific rules and special cases fossilized into the modern Web. You can't define the Same Origin Policy with a small short description that correctly captures essential details: the special cases actually matter in practice.
The rules for cookies are the rules of JS, and they aren't even perfectly well defined and browser independent. Cookies are very weakly protected in the modern Web because of these fossilized rules, which must be accounted for in the design of secure Web identification:
On the opposite, modern Web technologies that can store data (like localStorage and sessionStorage) on the browser store (together with the "cookie jar") are segregated strictly by origin with exact domain and URL scheme.
The inclusion of an image from another site doesn't have to be done with an object with specified dimensions (unlike the frame elements where the layout is specified by the frameset page or page hosting the iframe), so the layout depends on the dimensions of the loaded image; at least a Webpage can verify whether an image URL can be loaded, which can sometimes tell whether a user is logged on a Website for example.
The rules for loading scripts and style sheets are special; this is a hole in the policy that's useful for interfacing with other domain: a script loaded from the domain providing the service can set some variable to store the result of a computation. This very dirty way to do remote procedure calls is called "JSONP".
And then, there are side channels for measuring load time of ressources a page doesn't have the right to see or measure...
Image tags only send a GET request to the target and grab the contents if the target is an image. Try and embed a page with sensitive information within an image tag, it will send a GET request, but won't return anything of a sensitive nature.
Javascript has the potential to send you to a page, and return the contents of the page (using ajax this can be accomplished).
This is obviously problematic, as some pages will contain some sensitive information, and as such, it should only be possible with certain APIs and pages within the same website.
