<i>Arbitrary</i> requests to localhost aren&#x27;t permitted, unless the page itself is on localhost. (Just as evil.com can&#x27;t make <i>arbitrary</i> requests to google.com.) That said, there&#x27;s a bunch of exceptions. They don&#x27;t really matter here: the bug reported showed than an exploit was possible with a GET request, and you don&#x27;t need AJAX to make a GET request. A &lt;script&gt; or an &lt;img&gt; tag is, under the hood, a GET request. Taking the second case (making a GET request through an &lt;img&gt; tag), the response likely won&#x27;t be an image, so it won&#x27;t display, but we don&#x27;t know that until long after the request has executed, so it&#x27;s too late.<p>You&#x27;d have to restrict where images can come from (people wouldn&#x27;t be able to use CDNs?), where scripts come from (a lot of sites load jQuery from Google), you couldn&#x27;t allow JS redirects. You&#x27;d have to forbid JS from automatically submitting &lt;forms&gt;. CSS on odd domains. Webfonts. Videos, audio. I&#x27;m sure there are things I&#x27;m missing.<p>Back on the AJAX side of things, JS can make GET requests through AJAX. The server has to send back a special header for the script to get the response, but if it doesn&#x27;t, the request is still executed. (The idea being that, since you can execute GET requests using any of the aforementioned methods, allowing JS to do it isn&#x27;t going to allow anything new. GET also isn&#x27;t supposed to have side effects like this buggy endpoint has … GET was an extremely poor choice here.)<p>More arbitrary requests are permitted, but only under the condition explicitly allows them with what is called a preflight request. (Note that GET isn&#x27;t the only exception to preflighting, see [1].)<p>[1]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Access_control_CORS" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Access_con...</a>