Arbitrary requests to localhost aren't permitted, unless the page itself is on localhost. (Just as evil.com can't make arbitrary requests to google.com.) That s

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