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.

  • It does violate the policy, but it's a minor violation. JS invoked from a page is much more egregious violation!
    – curiousguy
    Aug 7, 2018 at 13:06

4 Answers 4


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.

  • 1
    But where is this exception codified? Are there others like it? Can I use an Access-Control-* header to block even images from being loaded by a foreign website? Mar 13, 2021 at 1:39
  • I couldn't find any codification of this exception either :(
    – nhooyr
    Sep 20, 2022 at 15:38

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:

  • The degree of communication between subdomains allowed by cookies is extremely useful (one subdomain can set a cookie that is used by another) but also a potential source of confusion, as the browser will not send back a cookie with the name of the domain that set it.
  • A cookie set on an http Webpage will be sent back on the same domain on an https Webpage, without indication of origin.

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.

  • 1
    "won't return anything of a sensitive nature" - To be a bit pedantic, this is false. Chrome blocks it and gives this link for explanation, but Firefox (and I expect most other browsers) will happily return the content. It'll likely not be a valid image, cause an error, and the response won't be accessible to the JavaScript anyway, but it will return it. Jul 26, 2018 at 20:31
  • Sorry, but this does not make sense. "Try and embed a page with sensitive information within an image tag, it will send a GET request" - what does "embed a page ... within an image tag" even mean?
    – sleske
    Jan 17, 2020 at 10:08
  • That would obviously be to attempt to point an image source at a page. Nothing sensitive will be accessible to a bad actor. May 18, 2020 at 13:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .