Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

From what I understand, the same origin policy prevents scripts in a web page from talking to servers outside of the present domain (using post, xmlhttprequest, etc). I assumed that get requests (with arguments) across domains would also be forbidden. That was until I started to read about using YQL to bypass some restrictions of the same origin policy. The code examples all use an ajax get request with parameters.

      type: "GET",
      url: '' + encodeURIComponent(webServiceQuery),

So lets say some attacker manages to inject some evil javascript into a web page that harvests logins. Something like:

  type: "GET",
  url: '

The receiving server could log every request that comes its way. Why is this allowed? I understand why you would want to allow data-less get requests (say importing jquery), but I don't see a reason to allow query strings to be passed cross domain. Is there a legit reason why most browsers allow this?

share|improve this question
Are you seeing this across all browsers or only a subset? – Steve Jun 18 '12 at 20:53
I've tested in chrome and firefox and it works fine – CountMurphy Jun 18 '12 at 21:28
I personally never used YQL. So I don't know much about it. But on the basic level there are way to make exceptions to same origin policy. Have a look at CORS and UMP - – Kapish M Jun 18 '12 at 21:30
cracker? don't use this term, ever. There are attackers, and defenders in software. – rook Jun 18 '12 at 22:26
up vote 11 down vote accepted

I don't see a reason to allow query strings to be passed cross domain. Is there a legit reason why most browsers allow this?

There is nothing special about query strings. You could just as well exfiltrate the information in a path part, or even the domain name. eg imagine setting the address to; if you run the DNS for you can easily log the lookups.

As per XMLHttpRequest level 2, browsers allow cross-origin GETs to be sent without preflighting, but don't allow the results to be read from the response unless the remote domain opts in. There is no additional vulnerability here because you can already cause a GET to an arbitrary URL to be sent (including query string, for what it's worth) through multiple more basic interfaces.

For example you have always been able to create an <img> element with its src set to an address on a remote domain; taking away that cross-domain ability would break a lot of the existing web.

share|improve this answer
+1 for a very key point: "there is nothing special about the query string" – Cheekysoft Jun 19 '12 at 14:29
"no additional vulnerability here" +1 There is no point making newer API strictly safer (strictly less powerful) if the older ones are never going to disappear! – curiousguy Jun 30 '12 at 13:59

The Same-Origin Policy prevents scripts from reading content from a location that the script does not originate from. CSRF attacks rely on the fact that you can transmit requests to another domain, and reading the response doesn't matter. Many CSRF prevention techniques exploits the fact that the attacker cannot read the page before making the request. When you load a web page many requests to many domains are fired to load content such as images, css and even javascript. Blocking requests to another domain would break important functionality.

XSS allows an attacker to execute arbitrary JavaScript that originates from a target website. The samy worm used this property of XSS to read the CSRF token and forge requests.

With the advent of "HTML 5" and CORS, you can build an arbitrary request using a xhr and use this to exploit CSRF vulnerabilities. The XHR will fire the request, however if the CORS HTTP reponse headers are not present then the XHR will fail to read the response... However, in order for the browser to see if these http response headers are present, it must first make the request. This behavior is very useful for building CSRF exploits such as cross-site file upload attacks that wouldn't normally be possible.

share|improve this answer
Minor correction: SOP prevents scripts from reading content from a location that the script is running at (i.e. the address of the web page that loads the script). – Krzysztof Kotowicz Jun 19 '12 at 10:36
@Krzysztof Kotowicz I think you mean IS NOT running at. – rook Jun 19 '12 at 17:47
"The Same-Origin Policy prevents scripts from reading content from a location that the script does not originate from" with special cases for including scripts, CSS (content served as text/css), and images (can get the dimension). The Privacy-related side channels section in the linked Browser Security Handbook is a must-read! – curiousguy Jun 30 '12 at 14:10
@rook: 'The Same-Origin Policy prevents scripts from reading content'. Just need a small clarification on this. If it prevents browser/script from reading the response, can it by read by a proxy in between. In other words, does the server even respond to such a request? – Rahil Arora Apr 15 '15 at 22:55
It depends on the XHR. But yes for the purposes of CSRF, you should assume that the client can send arbitrary requests, and that the response may be sent by the server, but not visible to the attacker. – rook Apr 16 '15 at 3:46

It's all a part of supporting cross domain ajax requests. You can do a GET, but the x-access-control-* headers determine whether the client can read the response or not.

If this was not possible, an attacker could still achieve the same by doing form submits with Get as method, or setting iframes/script/img tags with src attributes pointing to the same GET url. So this doesnt really change anything with regard to SOP unless the x-access-control-* headers are used.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.